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Abstract 

This  research  addresses  the  problem  of  verifying  implementations  against 
specifications  through  an  innovative  logic  approach.  Congruent  weak  conformance,  a 
formal  relationship  between  agents  and  specifications,  has  been  developed  and  proven  to 
be  a  congruent  partial  order.  This  property,  symbolized  hw,  arises  from  a  set  of  relations 
called  weak  conformations .  The  largest,  called  weak  conformance,  is  analogous  to 
Milner’s  observational  equivalence.  Unlike  observational  equivalence,  however,  weak 
confonnance  is  not  an  equivalence,  but  rather  an  ordering  relation  among  processes. 
Like  the  previous  property  of  logic  conformance,  weak  conformance  allows  behaviors  in 
the  implementation  that  are  unreachable  in  the  specification.  Unlike  logic  conformance, 
however,  weak  conformance  exploits  output  concurrencies  and  allows  interleaving  of 
extraneous  output  actions  in  the  implementation.  Finally,  reasonable  restrictions  in 
design  models  strengthen  weak  confonnance  to  a  congruence.  Being  both  congruent  and 
a  partial  order,  it  merits  the  customary  tenn  precongruence.  At  this  writing,  >-w  is  the 
best  known  fonnal  relation  for  verifying  implementations  against  specifications.  This 
precongruence  derives  maximal  flexibility  and  embodies  all  weaknesses  in  input,  output, 
and  no-connect  signals  while  retaining  a  fully  replaceable  conformance  to  the 
specification.  This  desirable  relation  is  described  in  four  transitional  laws  with  five 
constructional  restrictions. 

Congruent  weak  confonnance  has  additional  utility  in  verifying  transfonnations 
between  systems  of  incompatible  semantics  such  as  found  in  circuit  development, 

xiii 


security  system  design,  and  software  engineering.  This  dissertation  describes  a 
hypothetical  translator  from  the  informal  simulation  semantics  of  VHDL  to  the 
bisimulation  semantics  of  CCS.  A  second  translator  is  described  from  VHDL  to  a 
broadcast-communication  version  of  CCS.  By  showing  that  they  preserve  congruent 
weak  conformance,  both  translators  are  verified. 


CONGRUENT  WEAK  CONFORMANCE 


I.  Introduction 

Engineers  are  continually  challenged  to  produce  electronic  designs  that  meet 
specification;  and  logisticians  are  forever  seeking  replacements  for  obsolete,  non- 
procurable  microcircuits.  Thus  there  is  a  general  need  to  find  circuits  and  circuit  models 
that  are  “equivalent”  either  to  a  specification  model  or  to  some  obsolete  part  that  needs  to 
be  replaced.  However  a  moment’s  reflection  reveals  that  equivalence  is  a  stronger  notion 
than  what  is  really  needed  or  desired. 

First  of  all,  equivalent  speed  is  not  necessary.  One  can  often  replace  an  obsolete 
circuit  with  a  faster  circuit  of  equivalent  functionality.  This  approach  springs  from  the 
rationalization  that  the  faster  part  can  certainly  keep  pace  with  the  system  demands,  while 
any  tight  timing  constraints  simply  become  less  stringent.  However,  introducing  a 
speedier  component  can  uncover  race  conditions  and  hazards  that  were  safeguarded  by 
the  delays  inherent  in  the  original  component.  In  fact,  practitioners  often  deliberately 
introduce  delays  to  recover  timing  safeguards  when  faster  parts  are  used. 

Secondly,  excess  or  redundant  circuitry  in  the  implementation  can  often  be 
tolerated.  The  extra  circuitry  can  simply  sit  idle,  with  pins  either  unconnected  or 
grounded.  Also,  unneeded  behaviors  at  connected  pins  can  often  be  ignored  during 
certain  phases  of  the  execution. 

Thirdly,  options  allowed  by  output  concurrency  can  be  exploited.  If  the 
specification  calls  for  the  production  of  two  concurrent  outputs  x  and  y,  then  both  output 
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interleavings :  x  followed  by  y,  and  y  followed  by  x,  are  admissible.  The  original 
implementing  device  may  consistently  produce  one  interleaving  with  the  replacement 
device  producing  the  other  interleaving.  One  would  never  consider  the  two  devices 
“equivalent,”  yet  each  may  serve  equally  well  within  a  specific  application. 

This  dissertation  introduces  a  new  property  called  congruent  weak  conformance 
to  capture  the  desired  relationship  between  a  specification  and  a  compliant 
implementation.  Congruent  weak  conformance  is  not  a  true  equivalence,  but  rather  a 
partial  order  that  formally  embodies  intuitive  notions  of  compliance.  This 
precongruence  is  the  least  constraining  formal  relation  known,  as  of  this  writing,  for 
verifying  implementations  against  specifications.  It  derives  maximal  flexibility  and 
embodies  all  weaknesses  in  input,  output,  and  no-connect  signals  while  retaining  a  fully 
replaceable  conformance  to  the  specification.  This  desirable  relation  is  described  in  four 
transitional  laws  with  five  constructional  restrictions. 

Congruent  weak  conformance  also  provides  a  link  between  formalisms  of 
differing  semantics.  Whenever  transformations  are  proposed  for  translating  from  one 
representation  to  another,  congruent  weak  confonnance  must  be  preserved  by  such 
transfonnations,  even  when  other  semantic  information  is  lost.  In  particular, 
transfonnations  from  the  informal  simulation  semantics  of  hardware  description 
languages  such  as  VHDL  (IEEE,  1993)  to  process  algebras  such  as  the  Calculus  of 
Communicating  Systems  ( CCS)  (Milner,  1989)  can  be  validated,  allowing  stricter 
verifications  of  VHDL  models  based  on  the  bisimulation  semantics  of  CCS. 

1.1  Background 

The  design  of  digital  very-large-scale  integrated  (VLSI)  circuits  will  be  greatly 
aided  if  formal,  high-level  languages  support  all  life  cycle  activities,  including: 
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specification,  simulation,  synthesis,  verification,  documentation,  testing,  procurement, 
replacement  and  reengineering.  Such  languages  provide  the  opportunity  to  automate 
many,  if  not  all,  of  these  activities.  Such  automation  in  turn  decreases  expense,  shortens 
delivery  time,  and  increases  the  likelihood  that  delivered  parts  meet  the  user’s  needs. 

1.1.1  Language-based  Life  Cycle  Activities.  An  example  of  such  a  high-level 
language  is  the  VHSIC  Hardware  Description  Language  (VHDL),  a  standardized 
language  managed  by  the  Institute  of  Electrical  and  Electronic  Engineers  (IEEE).  The 
United  States  Department  of  Defense  (DoD)  has,  in  the  past,  required  VHDL  for 
microcircuit  documentation  (DoD,  1992). 

The  semantics  of  VHDL  is  presented  informally  in  the  VHDL  Language 
Reference  Manual  as  simulation  semantics  (IEEE,  1993).  Having  such  semantics,  VHDL 
is  widely  used  as  the  input  language  for  the  simulation  of  digital  electronic  components 
and  systems.  Designers  use  simulation  to  predict  the  behavior  of  their  designs  before 
implementation.  During  simulation,  a  behavioral  VHDL  model,  which  represents  a  set 
of  requirements  (specification),  and  a  structural  VHDL  model,  which  represents  a 
physical  design,  are  compared  by  being  subjected  to  the  same  set  of  input  stimuli  known 
as  a  VHDL  test  bench.  Thus  the  language  has  an  up-front  role  in  the  design  process  by 
expressing  specification  requirements  and  by  aiding  in  the  debugging  of  new  designs. 
Another  major  use  of  VHDL  is  as  the  input  language  for  the  automatic  synthesis  of  a 
design  directly  from  a  specification. 

VHDL’s  support  for  microcircuit  testing  is  solidified  through  ongoing  work  on 
the  WAVES  standard  (IEEE,  1991).  WAVES  is  a  standardized  subset  of  VHDL  used  for 
the  description  of  test  vectors.  Adherence  to  the  WAVES  standard  will  assure  that  the 
same  vectors  used  to  check  out  a  hardware  design  can  be  used  to  test  the  physical 
hardware  as  well. 
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Having  supported  other  life  cycle  activities,  if  VHDL  can  now  support  formal 
verification  as  well,  it  will  have  a  strengthened  role  as  the  lingua  franca  of  electronic 
design. 

1.1.2  Life  Cycle  Terminology.  To  alleviate  confusion  that  may  result  from  vague 
and  overlapping  usage  of  certain  common  terms  that  refer  to  various  aspects  of  the 
integrated  circuit  life  cycle,  the  following  usage  will  apply  in  the  ensuing  discussion: 

System.  The  term  system  refers  to  the  end  item,  box,  appliance,  or  printed 
circuit  board  that  uses  integrated  circuits  as  components.  The  system  design  effort  is  a 
separate  and  higher  level  function  than  component  design,  yet  intimate  knowledge  of 
component  behavior  is  used  in  the  system  design  process. 

Component.  A  component  is  a  single,  monolithic  integrated  circuit.  The 
terms  part  or  device  may  also  be  used  to  designate  a  component. 

Implementation.  This  is  the  physical  realization  of  a  component. 

Design.  The  term  design,  when  used  alone,  refers  specifically  to  the 
design  of  a  component  and  not  the  design  of  a  system  (which  is  explicitly  called  a  system 
design).  A  design  is  thus  some  representation  of  an  envisioned  implementation  for  some 
component.  Since  an  implementation  can  often  be  mechanically  generated  from  a 
completed  design,  the  terms  design  and  implementation  will  often  be  interchangeable. 

Designer.  Similarly,  a  designer  is  specifically  a  component  designer.  A 
system  designer  will  always  be  qualified  with  the  word  system. 

Environment.  For  each  of  its  components,  the  system  provides  an 
environment.  The  environment  is  the  complete  set  of  signals  by  which  the  component 
communicates  with  the  system.  Yet  it  is  more  than  a  simple  listing  of  such  signals,  for 
such  signals  are  often  preprocessed  or  “cleaned  up”  by  the  system.  Thus,  guarantees  or 
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restrictions  on  such  signals  are  also  considered  part  of  the  environment.  From  the  point 
of  view  of  a  component,  environment  and  system  are  synonymous. 

An  analogy  with  software  may  be  enlightening.  A  system  tasked  to  perform 
calculations  using  the  days  of  the  year  as  input  might  contain  twelve  component  modules 
which  service  each  month.  Erroneous  dates  such  as  October  35,  April  0,  and  February 
30  must  be  rejected.  The  system  designer  may  decide  that  dates  less  than  1  or  greater 
than  31  shall  be  rejected  at  the  top  level,  but  month-specific  problems  such  as  February 
30  shall  be  handled  by  each  specific  month.  Thus  the  environment  guarantees  to  each 
month  module  that  only  dates  in  the  range  1  to  31  will  be  passed  on.  The  February 
module  designer  will  incorporate  checks  to  reject  February  30  and  31.  He  will  not 
incorporate  code  for  negative  dates  because  the  system  guarantees  the  module  will  not 
see  them.  In  fact,  the  prudent  module  designer  will  exploit  this  fact  to  optimize  his  code. 
It  is  quite  acceptable  for  the  February  module  to  produce  all  kinds  of  outlandish  or 
“unspecified”  behavior  in  the  region  that  the  system  guarantees  it  will  never  reach. 

Behavior.  Behavior  denotes  what  a  component  does  or  is  required  to  do. 
When  speaking  in  terms  of  behavior,  one  should  avoid  reference  to  any  particular 
implementation  of  that  component.  Behavior  has  two  aspects:  function  and  timing. 

Function.  Function  denotes  the  action  of  a  component  that  transforms 
inputs  into  outputs.  The  speed  at  which  this  occurs  is  not  considered  part  of  the  function. 

Timing.  Timing  refers  to  the  speed  of  a  component,  together  with  any 
ordering  of  events  that  may  have  to  be  enforced. 

Supplier.  The  supplier  is  the  institution  that  is  legally  responsible  for  the 
performance  of  a  component.  Normally,  the  supplier  is  the  physical  manufacturer.  The 
component  designer  is  usually  an  employee  of  the  supplier,  but  not  always. 
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Customer.  The  customers  are  those  who  procure  and  apply  ICs  that  go 
into  systems.  This  includes  not  only  those  who  design  and  manufacture  the  original 
system,  but  also  those  who  perform  maintenance  on  such  systems.  Logistics  agencies 
that  procure  spare  and  replacement  parts  are  also  customers. 

1.1.3  Specification  Models.  In  1992,  MIL-STD-454L,  Requirement  64  (DoD, 
1992),  was  amended  to  require  that  VHDL  behavioral  and  structural  models  be  delivered 
to  the  DoD  for  all  newly  procured  military  integrated  circuits.  In  that  same  year,  the 
Defense  Electronics  Supply  Center  (DESC)  received  funding  from  the  Air  Force’s 
Producibility,  Reliability,  Availability  and  Maintainability  (PRAM)  office  to  develop  a 
repository  for  these  VHDL  models  (Noh,  1994).  Such  a  role  is  the  natural  extension  of 
DESC’s  traditional  role  of 

(1)  producing  hard-copy  specifications  of  military  ICs,  and 

(2)  maintaining  design  documents  of  devices  supplied  as  “compliant”  to  these 
specifications. 

The  Defense  Supply  Center  Columbus  (DSCC)  assumed  the  DESC  mission  after 
the  two  centers  merged  in  1996.  In  the  language-based  life  cycle  environment  DSCC  can 
expect  to  receive  two  kinds  of  VHDL  models: 

(1)  Behavioral  models  and  test  benches  to  serve  as  specifications. 

(2)  Structural  models  to  document  compliant  implementations. 

Upon  receipt  of  the  models  it  is  necessary  for  DSCC  to  approve  or  disapprove  them  on 
behalf  of  the  government  in  some  way,  as  DESC  has  done  in  the  past  with  hard-copy 
documents.  Of  course  DSCC  is  not  the  only  organization  to  face  such  challenges. 
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Not  everyone  relies  on  military  specifications.  In  fact,  the  DoD  itself  has  ceased 
relying  on  formal  military  specifications  (Perry,  1994).  Those  who  do  not  rely  on 
military  specifications  still  need  some  vehicle  to  serve  as  a  contract  between  customer 
and  supplier.  With  the  complexity  of  modern  integrated  circuits,  the  means  of 
determining  compliance  to  that  contract  must  be  fonnalized  and  automated  as  much  as 
possible. 

This  discussion  assumes  for  simplicity  that  the  system  designer  issues  a 
specification  for  each  system  component.  Suppliers  then  seek  to  implement  each 
specification.  This  does  not  mean  that  the  system  designer  actually  writes  each 
specification.  For  “off-the-shelf’  parts  an  adequate  specification  may  already  exist.  For 
new  parts,  or  for  poorly  specified  parts,  the  designer  may  develop  the  specification 
himself.  Nor  will  suppliers  always  blindly  accept  a  specification.  One  can  also  think  of  a 
specification  as  a  contract  between  a  component  and  its  environment  (Stevens, 
1994: 126).  Like  any  contract,  the  specification  is  often  an  object  of  negotiation. 

VHDL  behavioral  models  can  be  used  for  procurement,  replacing  hard-copy 
specifications.  Thus,  behavioral  specification  models  will  be  used  to  verify  the  structural 
models  that  document  implementations.  One  major  goal  of  language-based  design  is  to 
develop  a  formal  specification  that  is  faithful  (in  behavior  and  properties)  to  the  original 
informal  idea  of  the  system  designer.  A  second  goal  is  to  assure  that  the  specification  is 
“loose,”  expressing  only  the  required  properties  of  a  device  without  unduly  constraining 
the  component  design  and  manufacturing  processes. 

Many  properties  can  appear  in  a  specification  model.  These  may  include  fan-in, 
fan-out,  power  consumption,  physical  size,  pin  arrangement,  etc.  Foremost  in  the  mind 
of  most  designers  and  users,  however,  is  the  digital  behavior  (both  function  and  timing ) 
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of  the  device.  The  behavioral  aspect  is  so  dominant  that  most  devices,  such  as  “16-bit 
Adder”  or  “500  MHz  Microprocessor,”  are  overtly  named  accordingly  to  their  behavior. 

A  VHDL  model  used  for  a  specification  is  called  a  behavioral  model  because  it 
uses  the  “behavioral”  and  not  the  “structural”  constructs  of  the  language.  However,  it 
must  be  understood  that  a  specification  model  that  expresses  only  the  overt  surface 
behavior  of  a  device  will  be  incomplete.  Certain  invariant  properties — those  expected  to 
remain  constant  as  execution  proceeds — may  be  just  as  critical.  As  humans  we  tend  to 
focus  on  the  transformations  or  changes  wrought  by  a  device.  Invariant  properties  may 
not  be  the  focus  of  the  initial  specification  and  design  effort,  and  thus  may  be  overlooked. 
Webster’s  Ninth  Collegiate  Dictionary  defines  invariant  as  “unaffected  by  the  group  of 
mathematical  operations  under  consideration.”  Examples  of  such  invariant  properties  are 
safety,  liveness,  fairness,  and  deadlock. 

Safety.  Safety  denotes  the  property  that  a  device  will  not  be  presented 
with  any  inputs  it  is  incapable  of  handling.  As  a  constraint  on  the  environment,  safety  is 
more  often  an  obligation  of  the  system  than  of  the  device. 

Liveness.  Whereas  the  “ safety  property  claims  that  ‘something  bad’  does 
not  happen,”  the  liveness  property  assures  “that  ‘something  good’  eventually  happens.” 
(Manna  and  Pnueli,  1992:302).  “Liveness  properties  deal  with  eventualities — events 
which  must  occur  at  some  finite  but  unbounded  time.”  (McMillan,  1993:5)  In  other 
words,  liveness  assures  that  the  overt  behavior  we  desire  can  be  relied  upon  to  complete 
within  a  finite  time. 

Fairness.  The  fairness  property  ensures  “that  a  process,  once  initiated, 
will — sooner  or  later — get  the  opportunity  to  complete  its  actions”  (Dijkstra,  1968). 
Another  way  to  state  this  is  that  when  a  device  needs  some  resource,  it  will  eventually  get 
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that  resource.  Thus,  in  a  fair  system,  every  system  component  or  procedure  will  get  a 
chance  to  execute.  None  will  be  “starved.” 

Deadlock.  One  also  desires  freedom  from  deadlock.  A  deadlocked 
system  is  one  that  reaches  a  state  from  which  it  can  do  no  further  transactions.  In  the 
common  idiom,  the  system  has  “died”  or  “crashed.”  This  can  result,  for  example,  from 
an  “after  you”  situation,  where  two  communicating  components  are  each  awaiting  some 
action  or  acknowledgment  from  the  other. 

Function  and  timing  are  habitually  included  in  a  specification,  but  invariant 
properties  may  be  overlooked.  This  is  not  surprising.  Consider  the  property  of  deadlock. 
When  hard-copy  specifications  were  used,  and  the  designer  had  to  manually  interpret 
those  specifications,  it  was  intuitively  obvious  that  the  customer  did  not  want 
deadlocking  parts.  However,  modern  practice  uses  an  electronic  model  for  a 
specification,  and  an  automatic  synthesizer  does  the  “interpretation.”  What  if  the 
specification  model  itself  inadvertently  deadlocks?  The  synthesis  tool  may  faithfully 
implement  that  deadlock.  The  customer  will  have  no  legal  recourse  because  deadlock 
was  a  property  of  the  specification  he  supplied.  Verification  tools  will  not  protect  him, 
either,  for  they  will  simply  report  that  the  design  and  specification  are  “equivalent”  or 
that  the  design  “complies”  with  the  specification. 

Formal  verification  can  be  looked  upon  as  the  process  of  proving  that  invariant 
properties  always  hold.  In  fact,  the  desired  behavioral  transformation  of  a  device,  even 
though  it  expresses  change,  can  be  modified  into  an  invariant  fonn.  This  modified 
invariant  fonn  expresses  the  idea:  “it  is  always  true  that  we  will  get  what  we  expect.” 

1.1.4  Implementation  Models.  A  customer  may  or  may  not  require  design  and 
construction  documentation  from  the  device  supplier.  Such  documentation  describes  the 
design  and  construction  of  the  supplied  device  in  enough  detail  such  that  an  alternate 
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supplier  can  readily  remanufacture  it.  Commercial  customers  normally  do  not  need  such 
detailed  documentation,  and  cannot  get  it  anyway  since  many  design  and  manufacturing 
techniques  are  considered  proprietary.  However  the  DoD,  which  must  keep  critical 
military  systems  running  during  dire  emergencies,  often  requires  the  delivery  of  design 
and  construction  documentation  for  the  purpose  of  remanufacturing  in  case  the  original 
supplier  goes  out  of  business. 

Due  to  the  complexity  of  modem  microcircuits,  customers  will  require  design  and 
construction  documentation  in  the  fonn  of  a  structural  model — a  model  that  describes  the 
device  as  a  hierarchy  of  building  blocks  or  modules,  with  only  the  leaf-level  modules 
described  behaviorally.  Such  a  model  is  often  an  output  of  automatic  synthesis 
techniques,  where  a  device  is  built  from  a  library  of  available  subcomponents.  Although 
a  structural  model  has  behavior,  its  behavior  is  not  explicitly  stated,  but  is  the  product  of 
the  combined  behavior  of  its  interacting  subcomponents. 

1.1.5  Compliance  to  Specification.  With  machine-readable  models  for  both 
specification  and  implementation,  one  can  use  automatic  methods  to  assure  that  an 
implementation  is  compliant  to  its  specification.  What  does  it  mean  for  a  component  to 
comply  to  a  specification?  One  way  to  achieve  compliance  is  to  require  equivalence. 
The  notion  of  hardware  equivalence  is  not  a  trivial  one.  Examples  of  hardware 
equivalences  abound  (Bloom  and  Meyer,  1988;  Brookes  and  others,  1984;  De  Nicola  and 
Hennessy,  1984;  Groote  and  Vaandrager,  1988;  Hennessy  and  Milner.  1985;  Hoare,  1980; 
Milner,  1983  and  1989;  Olderog  and  Hoare,  1986;  Park,  1981;  Phillips,  1987;  Rounds 
and  Brookes,  1981).  Van  Glabbeek  has  identified  at  least  14  distinct  equivalence 
formalisms  (van  Glabbeek,  1990;  1990a).  Total  equivalence  between  component  and 
specification  is  not  desirable  anyway  because  it  is  too  restrictive.  A  good  specification 
lays  down  no  more  restrictions  than  the  system  absolutely  requires.  It  fonns  a  behavioral 
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envelope  within  which  the  design  must  perform.  The  behavior  of  a  good  design  will  be 
“guard-banded”  within  that  envelope.  A  compliant  design  will  be  capable  of  all  the 
behaviors  required  by  the  specification,  and  none  of  the  behaviors  forbidden  by  the 
specification.  However,  additional  behaviors,  and  even  additional  outputs,  are 
pennissible.  In  fact,  deviations  are  even  desirable,  since  the  exploitation  of  “don’t-care” 
states  can  improve  the  cost  and  efficiency  of  the  design. 

In  the  most  general  case,  the  implementation  does  not  imply  the  specification,  nor 
vice  versa.  In  the  space  of  possible  behaviors,  neither  set  of  behaviors  will  contain  the 
other.  To  illustrate,  consider  the  Venn  diagram  of  Figure  1-1 . 


The  intersection  of  the  specification  S  and  the  implementation  /  contains  within  it 
all  the  behaviors  of  S  that  are  required.  The  area  of  S  outside  of  the  required  behavior 
indicates  behavioral  options  that  the  implementation  can  select  from.  An  example  of 
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such  an  option  is  an  output  interleaving — when  the  specification  allows  two  or  more 
signals  to  be  generated  in  any  order,  but  the  implementation  uses  just  one  ordering. 
Outside  of  S  and  /  will  lie  behaviors  that  are  forbidden.  Between  S  and  the  forbidden 
behaviors  lie  “don’t-care”  behaviors.  The  area  of  /  outside  of  S  represents  additional 
behaviors  that  the  implementation  takes  on  in  order  to  achieve  efficiency. 

1.2  Problem  Statement 

Equivalence  is  a  mathematical  notion  that  avails  itself  of  such  tools  as  deductive 
logic  and  rigorous  proof.  Thus,  the  tools  of  mathematics  can  be  marshaled  to  determine 
the  equivalence  of  digital  circuits.  With  the  advent  of  modern  computers,  these  checks 
can  be  partially  or  totally  automated — thereby  eliminating  human  error  and  speeding  up 
the  process  of  microcircuit  verification.  However,  the  notion  of  compliance  to 
specification  is  not  an  equivalence,  as  Figure  1-1  shows.  The  modern  electronic  design 
life  cycle  will  benefit  if  the  notion  of  hardware  compliance  can  be  placed  on  the  same 
formal  footing  as  equivalences.  This  will  allow  formal  tools  to  evaluate  the  compliance 
of  devices  to  specification  models,  and  provide  a  means  to  validate  the  many 
transfonnations  used  during  the  design  process.  Such  transformations  ought  to  preserve 
a  fonnal  compliance  property  even  when  losing  other  properties.  Therefore,  the  goals  of 
this  research  are  five-fold: 

1.  Detennine  the  characteristics  of  a  compliant  device  with  respect  to  its 
specification.  Study  the  expected  behavior  of  an  implementation  in  response  to 
specified  input,  output  and  hidden  action.  Conversely,  note  any  reverse 
obligations  of  the  specification  to  implemented  input,  output  and  hidden  action. 
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2.  Incorporate  this  intuition  into  the  formally-defined  property  of  congruent  weak 
conformance  as  a  binary  relation  over  processes.  Make  this  fonnal  property  as 
“loose”  as  possible  such  that  it  admits  all  appropriate  implementations  and 
allows  the  most  design  flexibility. 

3.  Derive  fonnal  results  for  congruent  weak  confonnance  and  related  properties. 
Prove  that  congruent  weak  confonnance  is  a  partial  order.  Prove  also  that 
congruent  weak  conformance  is  fully  substitutable  in  all  contexts,  is  a  valid 
model  of  safe  substitution,  and  is  indeed  a  congruence. 

4.  Outline  the  transformations  necessary  to  create  a  semantic  link  from  VHDL  to 
CCS. 

5 .  Show  that  such  transformations  are  valid  by  proof  that  they  preserve  congruent 
weak  conformance,  thus  allowing  the  more  powerful  verifications  of  CCS  to 
accrue  to  VHDL  models. 

1.3  Organization  of  the  Dissertation 

Chapter  2  presents  the  prior  art,  describing  process  algebras  (in  particular  CCS), 
modal  and  temporal  logics,  various  equivalences,  fixed  points,  and  the  techniques  of 
coinduction  and  transition  induction.  Other  process  orders,  preorders  and  partial  orders 
from  the  literature  are  presented  as  potential  competitors  to  congruent  weak 
conformance.  These  ordering  relations  are  discussed  and  their  shortcomings  noted. 

Chapter  3  investigates  the  example  of  a  binary-coded  decimal  (BCD)  converter  as 
a  vehicle  for  extracting  intuitive  notions  of  device  compliant.  These  notions  are  then 
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formalized  by  four  transition  rules,  yielding  a  family  of  process  relations  called  weak 
conformations .  Weak  conformations  are  precursor  relations  that  will  be  refined  in 
subsequent  chapters.  Formal  results  governing  weak  confonnations  will  be  presented  as 
a  series  of  propositions  and  proofs. 

Chapter  4  presents  weak  conformance  >-w  (single  underline)  as  the  largest  of  the 
weak  conformations.  Further  formal  results  governing  >-w  are  proven  in  an  effort  to  show 
it  as  fully  substitutable,  that  is,  a  congruence.  That  attempt  stalls  pending  additional 
refinement  of  to  a  stronger  property.  Five  constructional  restrictions  are  then 
presented  as  requirements  governing  the  building  of  specification  and  implementation 
models.  These  restrictions  are  shown  to  be  reasonable  constraints  that  do  nothing  more 
than  codify  good  design  intent.  Congruent  weak  conformance  hw  is  then  defined  as  the 
>w  relation  as  refined  by  these  restrictions.  Additional  results  are  proven,  culminating  in 
the  demonstration  that  >-w  is  both  a  partial  order  and  a  congruence,  meriting  the  tenn 
precongruence.  This  establishes  >-w  as  a  correct  model  of  safe  substitution. 

Chapter  5  presents  a  VHDL  to  CCS  translation  scenario.  It  starts  with  simple 
circuits  of  sufficient  complexity  to  exhibit  the  semantics  of  VHDL  while  displaying  the 
salient  features  of  hw.  By  comparing  corresponding  VHDL  and  CCS  models, 
transfonnation  rules  are  derived.  Loss  of  information  such  as  the  explicit  timing  data  of 
VHDL  is  noted.  These  transformations  are  then  validated  by  proof  that  they  preserve  hw 
Thus  safe  substitution  is  preserved  by  these  transfonnations  despite  the  loss  of  other 
information. 

Chapter  6  then  presents  conclusions  and  recommendations  for  future  work. 

For  completeness,  Appendix  A  gives  a  definition  of  strong  conformation  to 
contrast  the  weak  conformation  concept  of  Chapter  3.  Strong  conformation  lacks  the 
utility  of  weak  conformation,  and  is  not  developed  further. 
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Appendix  B  contains  the  longer  proofs  that  would  otherwise  interrupt  the  flow  of 
the  dissertation,  and  Appendix  C  gives  the  transition  laws  for  the  process  algebra  CCS. 
Appendix  D  gives  the  “initial”  VHDL  models  for  the  BCD-converter  agents  S,  I  and  J 
given  in  Chapter  3.  Appendix  E  gives  the  translated,  or  “target”  VHDL  model  for  the 
BCD-converter  agent  S. 
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II.  Prior  Art 


This  chapter  discusses  previous  research  and  knowledge  leading  up  to  the  present 
research.  Section  2.1  presents  the  technique  of  simulation,  both  exhaustive  logic 
simulation  and  its  cousin  symbolic  simulation.  Formal  verification  and  its  two  main 
traditions:  theorem  proving  and  model  checking,  is  the  subject  of  Section  2.2.  Process 
algebras,  the  languages  used  to  model  concurrent  hardware,  follow  in  Section  2.3.  This 
dissertation  employs  the  process  algebra  known  as  the  Calculus  of  Communicating 
Systems  (CCS)  (Milner,  1989).  CCS  is  used  to  introduce  the  idea  of  equivalence  of  two 
process  algebraic  models  ( i.e .  circuits)  in  Section  2.4.  Of  the  many  hardware 
equivalences,  four  appear  here.  The  last,  observational  congruence,  is  the  appropriate 
equivalence  that  captures  the  notion  of  safe  substitution. 

Section  2.5  introduces  the  modal  and  temporal  logics,  which  have  the  power  to 
identity  equivalences  and  other  properties  of  process  agents.  These  logics  are  then 
extended,  by  means  of  the  fixed-point  notation,  into  the  modal  //  calculus.  The 
Concurrency  Workbench  (Cleaveland  and  others,  1989;  Cleaveland  and  Parrow,  1993)  is 
introduced  as  a  tool  whose  notation  greatly  simplifies  the  ungainly  notation  of  the 
modal  //  calculus,  and  allows  one  to  investigate  properties  of  CCS  agents  using  the  power 
of  bisimulation  (Park,  1981),  a  semantics  capable  of  stricter  verifications  than  the 
simulation  semantics  of  VHDL. 

Proofs  of  process  algebraic  propositions  often  require  the  technique  of  transition 
induction  (Milner,  1989:58,  100).  Transition  induction  is  a  variation  of  coinduction 
(A.  Gordon,  1995;  Rutten,  1996;  Jacobs  and  Rutten,  1997;  Wegner  and  Goldin,  1999). 
Coinduction  is  not  as  well  known  as  mathematical  induction.  Therefore  the  general 
techniques  of  coinduction  and  transition  induction  are  introduced  in  Section  2.6. 
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Sections  2.7  and  2.8  review  the  work  of  researches  whose  aims  appear  similar  to 
those  of  the  present  research.  These  contributions  fall  into  two  camps.  Section  2.7 
reviews  those  efforts  that  link  languages  such  as  VHDL  into  fonnal  methods.  Section  2.8 
reviews  various  process  ordering,  preordering  and  partial  ordering  relationships. 

2.1  Simulation 

The  VHDL  Language  Reference  Manual  refers  to  an  event-based  simulation  cycle 
to  define  its  constructs  (IEEE,  1993).  Thus,  a  set  of  informal  simulation  semantics  is 
assumed  for  VHDL  (van  Tassel,  1994).  This  is  consistent  with  the  current  practice  that 
verifies  designs  by  computationally  simulating  the  operation  of  the  design.  Simulation 
involves  the  submission  of  test  stimuli  to  the  device  model  while  observing  the 
responses.  Ideally,  the  designer  will  simulate  both  the  design  model  and  the  specification 
model,  checking  that  they  yield  the  same  results  under  simulation. 

A  VHDL  language-based  design  environment  will  represent  the  original 
requirements  (specification)  using  two  models:  (1)  a  VHDL  behavioral  device  model, 
and  (2)  a  VHDL  test  bench.  The  first  represents  the  specified  device  as  a  finite  set  of 
behaviors.  It  describes  the  transformation  of  inputs  to  outputs,  the  ordering  of  events, 
and  speed  requirements.  Ideally,  this  model  should  use  only  the  behavioral  constructs  of 
the  language.  It  should  not  suggest  an  internal  structure  that  may  unduly  limit  possible 
implementations.  The  test  bench  is  a  VHDL  model  used  to  exercise  the  device  model 
during  simulation.  It  contains  the  behavioral  device  model  as  a  component.  The  test 
bench  includes  a  set  of  test  vectors  that  represent  input  stimuli  and  the  expected  output 
responses.  During  simulation,  the  test  bench  submits  the  input  portion  of  each  test  vector 
to  the  device  model  and  compares  the  resulting  output  with  the  expected  output.  The 
behavioral  device  model  must  be  able  to  pass  this  simulation  before  a  specification  can 
be  released. 
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Later,  when  the  design  of  a  potential  implementation  arrives,  a  structural  VHDL 
model  that  represents  the  submitted  design  replaces  the  behavioral  device  model.  Ideally, 
this  model  is  synthesized  from  the  design  by  automatic  means.  The  simulation  is  then 
repeated  on  the  implementation  model.  If  this  model  also  passes  the  simulation,  then  the 
design  has  been  validated  to  be  a  correct  implementation  of  the  specification. 

For  simulation  to  be  totally  effective,  it  needs  to  embody  all  possible  behaviors. 
In  other  words,  the  test  vector  set  must  be  exhaustive  both  in  all  legal  timing  variations  as 
well  as  behavioral  variations.  Unfortunately,  the  complexity  of  modern  integrated 
circuits  militates  against  an  exhaustive  test  vector  set.  The  number  of  possible  test 
vectors  is  exponential  on  the  number  of  inputs.  Exhaustive  simulation  is  intractable  for 
modern  designs.  Actual  simulations  rely  on  a  limited  set  of  test  vectors  and  thus  do  not 
give  complete  verification  assurance. 

Symbolic  simulation  is  related  to  logic  simulation  (McMillan,  1993:126).  In 
ordinary  logic  simulation  the  test  vectors  consist  only  of  the  binary  constants  0  and  1.  In 
symbolic  simulation  a  vector  can  consist  of  Boolean  variables  and  functions  as  well  as 
constants.  Thus,  multiple  specific  instances  of  behavior  can  be  abstracted  away  and 
verified  as  a  class. 

2.2  Formal  Verification 

As  an  alternative  to  simulation,  researchers  have  investigated  the  use  of  formal 
methods  to  verify  hardware.  Formal  verification  seeks  to  establish  the  correctness  of 
designs  by  means  of  mathematical  proof  (McMillan,  1993:1). 

There  are  two  common  fonnal  verification  traditions,  theorem  proving  and  model 
checking  (McMillan,  1993:2).  The  theorem  proving  approach  models  the  device  and  its 
specification  in  a  formal  logic.  The  device  model  constitutes  the  “axioms”  of  a  formal 
system.  This  approach  then  seeks  to  construct  a  proof  leading  from  the  axioms  to  the 
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specification.  In  other  words,  the  device  model  should  logically  imply  the  specification. 
Unfortunately,  these  proofs  can  be  lengthy,  and  the  process  is  not  fully  automated. 

The  model  checking  approach  is  also  a  proof  based  approach,  but  it  is  restricted 
so  that  full  automation  can  be  achieved.  During  model-checking,  the  device  is  modeled 
specifically  as  a  finite  state  machine,  and  specifications  are  written  as  logical  assertions 
to  be  proved  about  that  specific  finite  state  machine. 

Formal  verification  by  model  checking  and  VHDL  validation  through  simulation 
share  a  similarity.  Both  approaches  use  a  two-part  specification.  The  first  part  is  a  model 
of  the  proposed  device  as  a  finite  set  of  behaviors.  Requirements  for  the  device  model  to 
meet  appear  separately.  For  a  VHDL  simulation-based  environment,  requirements  are 
embodied  in  the  test  bench  as  a  voluminous  set  of  test  vectors.  In  the  model-checking 
environment,  requirements  are  expressed  more  concisely  as  a  set  of  logical  assertions. 

2.3  Process  Algebras 

The  subtle  properties  of  liveness,  fairness,  and  deadlock  become  issues  when 
dealing  with  the  parallelism  and  concurrency  inherent  in  structural  models.  Consider  that 
a  truly  non-parallel  uniprocessor  would  have  no  means  of  deadlocking  unless  it  were 
designed  with  an  explicit  HALT  instruction.  Unfortunately,  such  a  processor  is  only  an 
abstraction.  Digital  electronic  hardware,  being  made  up  of  physical  components  that 
operate  in  real  time,  is  inherently  concurrent  and  parallel,  and  thus  deadlock  is  a 
possibility. 

Process  algebras  such  as  the  Calculus  of  Communicating  Systems  (CCS) 
(Milner,  1989)  and  Communicating  Sequential  Processes  (CSP)  (Dijkstra,  1968;  Hoare, 
1985)  are  used  to  model  concurrency  and  thus  are  useful  for  modeling  digital  electronic 
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hardware.1  CCS,  for  example,  is  a  very  concise,  but  highly  expressive  language.  It  has 
mechanisms  for  both  behavioral  and  structural  modeling.  Especially  important  are  its 
mechanisms  for  expressing  non-deterministic  choice  and  hidden  internal  action. 
Processing  elements  are  known  as  agents,  and  are  often  recursive. 

Consider  the  asynchronous  communication  device  called  the  C  element  (Shams 
and  others,  1998).  The  C  element  awaits  the  arrival  of  two  concurrent  inputs  a  and  b. 
Once  both  have  been  received,  an  output  c  is  produced.  Equation  2-1  is  the  CCS  model 
of  the  C  element’s  behavior: 


C  ='  abc.C  +  bnc.C  (2-1) 

Being  concurrent,  the  input  signals  a  and  b  may  arrive  in  either  order.  This  allowance  is 
indicated  by  alternative  execution  branches  separated  by  No  matter  which  branch  is 
selected,  the  output  c  is  emitted  after  inputs  a  and  b  are  received.  Following  the  output, 
the  agent  returns  to  the  initial  state  C,  ready  to  receive  more  inputs. 

CCS  processes  (or  agents)  appear  in  upper  case.  Lower  case  names  serve  as 
transition  labels,  with  output  transitions  bearing  an  overbar."  There  are  six  CCS 
combinators  or  operators: 

def 

•  The  Constant  operator,  ‘  =  ’,  which  assigns  an  agent  name  to  a  behavior. 

•  Prefix,  denoted  by  the  period,  to  indicate  one  action  following  another. 

•  Choice  or  Summation,  denoted  by  ‘+’,  to  indicate  a  fork  in  the  execution  path. 


1  Process  algebras  are  also  commonly  called  process  logics,  but  this  dissertation  maintains  a  distinction. 
“Process  algebra”  is  reserved  for  languages  that  represent  closed  systems  of  processes  and  operations  that 
transform  them.  “Process  logics”  are  systems  that  manipulate  predicates  defined  over  process  algebras. 

2  When  an  overbar  is  typographically  difficult  it  is  customary  to  use  a  leading  “tic”  mark:  'c. 
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•  Parallel  Composition,  denoted  by  ‘(A  \  B )’  to  indicate  agents  A  and  B  operating 
concurrently. 

•  Relabeling.  The  notation  ‘  E\x/y\ ’  indicates  that  transition  x  has  been  renamed  to  y  in 
the  agent  E . 

•  Restriction,  denoted  by  the  backslash  character  ‘V. 

To  accomplish  behavioral  modeling  in  CCS,  the  first  three  combinators: 

-5 

Constant,  Prefix  and  Choice,  suffice.  Furthermore,  the  Choice  operator  can  also  be  used 
to  express  non-deterministic  behavior.  Consider  the  agent: 


COIN  =  flip,  heads  .COIN  +  flip,  tails  .COIN  (2-2) 

Here  the  environment  can  exert  no  control  over  the  outcome,  since  the  input  flip 
occurs  in  both  branches.  Once  a  flip  arrives,  the  COIN  agent  non-detenninistically 
selects  one  branch,  and  produces  an  output  accordingly.  In  this  instance  +  involves  an 
internal,  or  non-deterministic  Choice.  However,  +  is  not  always  the  harbinger  of  non¬ 
determinism.  The  external  Choice  expressed  in  the  C  element  specification  (Equation 
2-1)  is  perfectly  predictable  due  to  the  environment’s  ability  to  control  the  input  sequence 
and  select  which  branch  is  executed. 

Like  the  C  element  and  the  COIN  agent,  most  useful  CCS  agents  are  recursive  in 
their  behavioral  description.  Real  hardware  agents  do  not  simply  compute  some  result 
and  terminate.  They  more  closely  resemble  what  Manna  and  Pnueli  call  reactive 
programs  (Manna  and  Pnueli,  1 992: vii).  Rather  than  halting,  they  forever  await  inputs 
from  their  environment,  respond,  and  then  wait  again. 


3  Consistent  with  Milner’s  usage,  combinator  names  are  capitalized  to  distinguish  them  from  their  common 
English  meanings. 
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The  last  three  combinators:  Parallel  Composition,  Relabeling  and  Restriction,  add 
the  ability  to  perform  structural  modeling.  As  an  example,  consider  the  behavior  of  a 
simple  one  place  buffer  or  FIFO : 


def 


FIFO  =  in.  out  .FIFO 


(2-3) 


One  can  build  a  two-place  FIFO  by  connecting  two  one-place  FIFOs  in  series,  as  shown 
in  Figure  2-1. 


FIFO 


FIFO 


Figure  2-1.  Two-place  FIFO 


This  composite  construction  FIF02  is  modeled  in  CCS  as  follows: 


FIF02  =  ( FIFO\mid/out\\  FIFO\mid/in\)\{mid }  (2-4) 

The  Parallel  Composition  (  FIFO...|  FIFO...)  denotes  the  building  of  a  composite  model 
from  two  submodels — in  this  case  two  identical  FIFOs.  The  Relabeling  functions 
[mid/out\  and  [mid/ in]  then  rename  two  of  the  ports  to  mid  and  mid.  This  forms  an 
implicit  internal  connection.  Any  communication  between  the  components  of  a  Parallel 
Composition  is  accomplished  when  actions  and  co-actions  share  the  same  label,  differing 
only  by  the  overbar.  In  the  parlance  of  hardware  description  languages,  Relabeling 
expresses  the  “named  association”  of  an  actual  signal  mid  to  internal  signals  in  and  out. 
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The  Restriction  mechanism  \{mid }  in  turn  hides  the  internal  signal  mid  from  the 
external  environment.  The  signal  ceases  to  be  a  port  to  the  outside  world.  In  that  sense 
the  Restriction  operator  models  abstraction  by  hiding  a  lower-level  detail.  This  hiding  of 
internal  signals,  which  is  implicit  in  hardware  description  languages  such  as  VHDL,  must 
be  stated  explicitly  in  CCS  by  means  of  the  Restriction  mechanism. 

In  its  treatment  of  internal  action,  CCS  differs  significantly  from  languages  such 
as  VHDL  where  internal  action  is  not  represented  at  higher  levels  of  abstraction.  In  CCS, 
such  hidden  action  is  denoted  by  the  symbol  z.  All  silent  actions  are  abstracted  into  this 
single  symbol.  Practitioners  will  sometimes  use  a  subscript  such  as  zm(i  to  track  the 
origin  of  these  actions,  but  the  subscript  is  semantically  meaningless  within  the  context  of 
CCS. 

After  expanding  each  FIFO  and  Relabeling  their  ports,  one  can  rewrite  FIF02  as 
FIFO 2  '=  ( in.mid.FIFO\mid.out.FIFO)\{mid }  (2-5) 

where  =  is  syntactic  identity.  Using  a  single-shaft  labeled  arrow  to  denote  atomic 
transitions  one  writes 

FIFO 2  (mid. FIFO  \  midxmt.FIFO)\{mid}  (2-6) 

At  this  point  the  renamed  signals  mid  and  mid  can  communicate  or  synchronize,  and  the 
next  transition  is  a  z. 

( mid.FIFO  \  mid.out. FIFO  )\{mid} -A  ( FI FO\out. FIFO )  \mid\  (2-7) 
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The  compound  agent  conducts  a  silent  action  by  transferring  a  datum  from  the  first  to  the 
second  FIFO.  Though  unseen,  this  hidden  action  does  indeed  affect  the  behavior  of  the 
compound  agent.  The  evolving  FIF02  cannot  accept  a  second  in  action  until  this 
internal  transfer  occurs. 

Because  the  composite  agent  FIF02  has  a  depth  of  two,  the  user  will  expect  it  to 
accept  two  inputs  before  an  output  is  issued.  Or,  if  an  output  is  issued  after  one  input, 
one  will  expect  that  FIFO 2  is  now  empty  and  can  accept  two  more  inputs.  Therefore, 
one  behavior  the  user  expects  is  in.in.out.  He  does  not  expect  to  be  delayed  at  all  if  he 

wishes  to  send  two  symbols  in  in  succession.  Yet  since  the  agent  FIF02  cannot  accept  a 
second  in  until  the  internal  action  has  transpired,  the  behavior  he  actually  gets  is 
in.T.in.out. 

Some  might  argue  that  the  r  interruption  is  inconsequential.  In  real  hardware 
such  internal  actions  occur  readily  enough  and  for  practical  purposes  they  can  be  ignored. 
Others  might  argue  that  unless  one  knows  the  target  technology  and  how  the  circuit  will 
be  laid  out,  it  is  wiser  to  assume  no  more  than  necessary  about  any  delay  associated  with 
internal  actions.  Designers  of  synchronous  circuits,  in  particular,  eliminate  the  need  to 
consider  internal  action  by  calculating  worst-case  delays  and  then  slowing  down  the 
system  clock  to  insure  no  internal  actions  are  pending  when  the  clock  advances. 
Asynchronous  designers  however,  who  use  no  clock,  must  take  note  of  internal  action  in 
some  way.  For  them,  the  r  mechanism  in  CCS  is  very  powerful. 

Differences  in  opinion  about  how  to  handle  internal  actions  (and  the  conditions 
under  which  they  must  be  respected  or  ignored)  give  rise  to  various  hardware 
equivalences — covered  in  the  next  section. 

2.4  Hardware  Equivalences 

An  equivalence  relation  divides  a  set  into  equivalence  classes.  Within  each 
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equivalence  class  all  members  are  equivalent  and  between  equivalence  classes  all 
members  are  distinct.  The  weakest  possible  equivalence  relation  simply  declares  all 
members  of  a  set  <P  to  be  equivalent.  The  strongest  possible  equivalence,  on  the  other 
hand,  distinguishes  every  member  of  <P,  placing  each  into  its  own  (singleton)  equivalence 
class.  Equivalence  relations  in  process  algebras  can  also  be  characterized  by  their 
strength  with  the  stronger  making  finer  distinctions  among  agents  and  the  weaker 
identifying  more  agents.  Modeling  accuracy  favors  stronger  equivalences,  whereas 
design  flexibility  favors  weaker  equivalences. 

Van  Glabbeek  has  listed  eight  semantic  criteria  that  characterize  various  hardware 
equivalences  [vG90a].  The  four  main  criteria  are: 

•  Linear  time  versus  branching  time.  Linear  time  semantics  distinguishes 
processes  based  on  the  content  of  their  observable  runs,  whereas  branching  time 
semantics  maintains  infonnation  where  different  courses  of  action  diverge. 

•  Interleaving  semantics  versus  partial-ordering  semantics.  This  distinction  relates 
to  the  expression  of  concurrency.  In  interleaving  semantics  there  is  only 
“liveness  on  a  symbol.”  CCS  is  an  example  of  interleaving  semantics.  Since 
symbols  are  only  issued  one  at  a  time  the  concurrency  between  two  symbols  must 
be  expressed  by  explicitly  giving  the  interleavings,  for  example,  a.b  +  b.a.  In 
partial  order  semantics,  also  known  as  “true  concurrency,”  there  is  “liveness  on 
symbols  and  transitions.”  Van  Glabbeek  lists  the  Petri  Net  discipline  as  an 
example  of  true  concurrency.  When  a  transition  is  live  it  can  fire  and  release 
multiple  tokens  without  specifying  the  interleavings  among  those  tokens. 

•  Abstraction  of  internal  action.  When  equating  agents,  internal  actions  can  be 
totally  ignored,  or  taken  into  account  in  various  ways. 
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•  Treatment  of  infinite  processes. 

Van  Glabbeek  has  identified  14  equivalences  (van  Glabbeek,  1990;  1990a).  Four  such 
equivalences  are  presented  here:  trace  equivalence,  strong  equivalence,  observational 
equivalence,  and  observational  congruence. 

2.4.1  Trace  equivalence.  Two  agents,  P  and  Q,  are  trace  equivalent  when  every 
sequence  of  visible  actions  produced  by  P  is  producible  by  Q,  and  vice  versa  (Milner, 
1989:204). 

Definition  2-1.  Process  agents  P  and  Q  are  trace  equivalent,  written  P  ~t  Q,  if  Vs  €  £*, 
P ^  iff  Q±>. 

This  is  a  common  sense  version  of  equivalence,  but  is  often  too  weak  for  many  purposes. 
Consider  the  agents: 


Y  =  a.  (b.NIL + c.NIL)  (2-8) 

V  =  ab.NIL  +  a.c.NIL  4  (2-9) 

The  two  agents  Y  and  V  are  indeed  trace  equivalent,  sharing  the  trace  set  {a,  a.b,  a.c }. 
However  their  observable  behaviors  are  not  the  same.  The  agent  Y,  after  performing  an  a 
action,  still  has  the  option  to  perfonn  either  b  or  c.  For  the  V  agent  however,  this  choice 
is  taken  away.  Upon  receipt  of  the  a,  the  V  agent  non-detenninistically  chooses  a  branch, 
evolving  to  either  b.NIL  or  c.NIL,  after  which  it  will  reject  either  c  or  b,  respectively. 

2.4.2  Strong  equivalence.  The  notion  of  strong  bisimilarity  addresses  this 
difference  in  observable  behavior  between  trace  equivalent  agents  (Milner,  1989:88). 
Two  agents,  P  and  Q,  are  said  to  be  strongly  bisimilar  if  each  can  perfonn  all  the  actions 

4  NIL  is  a  special  CCS  agent  that  can  do  no  actions,  and  can  be  considered  a  HALT. 
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of  the  other  and,  after  every  such  action  a,  the  immediate  successor  agents  ( a - 
derivatives),  P'  and  Q'  are  themselves  strongly  bisimilar.  Strong  bisimulation  is  thus  a 
binary  relation  among  agents.  Formally,  a  strong  bisimulation,  S,  satisfies  the  so-called 
“back-and-forth”  property: 

Definition  2-2.  A  binary  relation  S  among  processes  is  a  strong  bisimulation  if  Vaction 
a 

(i)  Whenever  P  -^P’  then  3 Q '  such  that  Q^NQ'  and  P'  SQ’. 

(ii)  Whenever  Q^Q'  then  3P'  such  that  fA  P'  and  P'  SQ'. 

Many  relations  satisfy  Definition  2-2,  including  the  empty  relation.  However  the  empty 
relation  is  not  useful,  since  it  equates  no  agents.  One  normally  wishes  to  equate  as  many 
agents  as  practical.  Therefore,  one  prefers  the  largest  strong  bisimulation  ~,  which  is 
called  strong  equivalence.  Strongly  equivalent  agents  each  match  the  actions  of  the 
other,  including  the  internal  action  r.  The  two  agents  V  and  Y  given  above,  though  trace 
equivalent,  are  not  strongly  equivalent.  Agent  V  has  two  ^-derivatives,  b.NIL  and  c.NIL. 
Neither  of  these  can  perform  all  the  actions  of  the  single  ^-derivative  of  Y,  b.NIL  + 
c.NIL,  which  can  perform  both  b  and  c. 

2.4.3  Observational  equivalence.  The  notion  of  strong  equivalence  is  too  strong 
for  many  purposes.  For  example,  strong  equivalence  distinguishes  between  the  agents 
a. NIL  and  a.  r.NIL: 


a. NIL  P  a.  r.NIL  (2-10) 

However  such  a  distinction  normally  makes  little  difference  to  users.  After  receiving  the 
a  action,  both  agents  eventually  evolve  to  NIL  and  halt  anyway. 
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Therefore,  the  notion  of  strong  bisimilarity  is  weakened  to  weak  bisimilarity 
(often  called  simply  bisimilarity),  which  abstracts  away  r  actions  (Milner,  1989:108). 
Weak  bisimulation  also  obeys  a  “back-and-forth”  property  in  a  manner  analogous  to 
strong  bisimulation: 

Definition  2-3.  A  binary  relation  ©  among  processes  is  a  weak  bisimulation,  if  Vaction  a 

(i)  Whenever  P-^P'  then  3 Q'  such  that  Q  =b>  Q'  and  P '  ©  (Q '. 

(ii)  Whenever  Q  ^>Q'  then  3 P'  such  that  P  =b>  P'  and  P'  <SQ'. 

The  hat  embellishment  A  above  an  action  or  an  action  sequence  removes  r  actions  from 
that  sequence.  Since  a  above  represents  single,  or  atomic  actions,  the  hat  notation 
changes  a  r  action  to  the  empty  sequence,  s.  All  other  actions  are  unchanged.  The 
double-shafted  arrow  =>,  on  the  other  hand,  allows  insertion  of  any  number  of  r  actions 
necessary  to  complete  a  transition.  Thus,  weak  bisimulation  differs  from  strong 
bisimulation  in  that  any  one  agent  can  match  the  r  actions  of  the  other  with  zero  or  more 
r  actions.  As  was  true  with  strong  bisimulation,  there  are  also  many  weak  bisimulation 
relations.  Again,  the  largest  weak  bisimulation  «,  called  observational  equivalence,  is 
the  most  interesting.  Note  that  a.  z.NIL  «  a.NIL.  These  two  agents  are  not 
distinguished  under  «,  as  they  are  under  ~. 

2.4.4  Observational  congruence.  A  motivation  for  finding  equivalent  hardware 
agents  is  to  safely  substitute  one  for  the  other.  This  safe  substitution  property  is  known 
as  congruence.  A  congruence  is  a  relation  that  is  preserved  by  every  operation  of  the 
underlying  algebra.  Alternately,  one  can  say  that  a  congruence  is  preserved  by  all 
contexts.  Consider  the  Prefix  operation.  If  P  ~  Q  then  one  hopes  that  a.P  ~  a.  Q.  In  other 
words,  the  Prefix  operator  ought  to  preserve  «.  This  is  one  congruence  law.  Under  CCS 
there  are  six  congruence  laws,  one  for  each  CCS  operator.  Unfortunately,  observational 
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equivalence  «  fulfills  only  five  of  the  six  laws.  It  is  not  preserved  by  Summation.  For 
example: 


yet, 


z.a.NIL  «  a. NIL 
b.NIL  sb  b.NIL 

z.a.NIL  +  b.NIL  *  a.NIL  +  b.NIL 


(2-11) 

(2-12) 

(2-13) 


because  the  initial  r  action  of  the  left  hand  agent  can  preempt  the  choice  allowed  by 
The  left-hand  agent  is  therefore  unstable  (Milner,  1989:112).  When  the  r  occurs,  the 
left-hand  agent’s  ability  to  perform  a  spontaneously  evaporates,  without  the  occurrence 
of  a  visible  action.  Meanwhile  the  right-hand  agent  can  still  perform  either  a  or  b. 
Clearly,  there  is  a  difference  between  the  “safe”  r  appearing  in  a.  z.NIL  versus  the 
preemptive  r  appearing  in  Equation  2-13.  That  difference  is  guardedness  (Milner, 
1989:65). 


Definition  2-4.  X  is  guarded  in  an  expression  E  if  each  occurrence  of  X  within  E  lies 
within  some  subexpression  IF  of  E,  where  £  is  a  visible  action,  t  ^  r. 

Only  visible  actions  can  serve  as  guards.  X  is  therefore  guarded  whenever  some  visible 
Prefixed  action  must  always  be  encountered  before  the  execution  can  proceed  to  X. 
Thus,  the  r  in  a.  r.Nil  (which  can  safely  be  ignored)  is  seen  to  be  guarded.  The 
unguarded  z  in  Equation  2-13,  however,  creates  an  instability  and  destroys  the 
congruence  of  «  under  Summation.  Hence,  the  property  of  observational  equivalence  is 
modified  to  that  of  observational  congruence  (Milner,  1989:153).  Observational 


2-14 


congruence  obeys  a  “back-and-forth”  property  similar  to  weak  bisimulation,  with  the  hats 
removed  from  the  action  symbol  a. 

Definition  2-5.  Process  agents  P  and  Q  are  observationally  congruent,  written  P  =  Q,  if 
Vaction  a: 

(i)  Whenever  _P-^>  P'  then  3 Q'  such  that  Q=>Q'  and  P'  ~  Q'. 

(ii)  Whenever  Q-^Q'  then  3P '  such  that  P=>P'  and  P '  ~  Q'. 

Observational  congruence  is  also  called  equality,  and  denoted  P  =  Q.  Under 
observational  congruence,  initial,  unguarded  r  actions  must  be  matched  r  for  r. 
However,  Definition  2-5  does  not  demand  the  ^-derivatives  P'  and  Q'  in  turn  to  be  =, 
merely  «.  Otherwise  guarded  r  actions  would  eventually  pop  out  and  be  evaluated  as 
unguarded.  Thus,  observational  congruence  continues  to  abstract  away  guarded  z  actions 
in  the  same  manner  as  «,  while  respecting  unguarded  r  actions.  Milner  shows  that  =  is  a 
slightly  stronger  equivalence  than  «,  which  can  be  derived  by  restricting  «  to  initially 
stable  agents  (Milner,  1989:Proposition  5-9). 

2.5  Modal  and  temporal  logic 

The  Edinburgh  Concurrency  Workbench,  or  CWB  (Cleaveland  and  others,  1989; 
Cleaveland  and  Parrow,  1993)  accepts  agents  described  in  CCS  and  test  them  against 
various  equivalences.  Thus,  one  can  present  a  specification  as  a  behaviorally  described 
CCS  agent.  A  candidate  implementation  can  be  presented  by  assembling  its  components 
using  the  Parallel  Composition  operator.  Specifications  and  implementations  are 
compared  for  equivalence.  However,  such  verifications  can  take  a  very  long  time  if  the 
agents  have  many  states.  In  many  instances,  it  is  more  convenient  to  check  agents  to  see 
if  they  satisfy  certain  defined  logical  properties. 
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2.5.1  Hennessy-Milner  Logic.  The  CWB  can  also  check  assertions  written  in  the 
Hennessy-Milner  Logic  (HML)  (Stirling,  1992).  Since  it  deals  with  assertions  about 
processes,  HML  can  be  called  a  process  logic.  Being  a  logic,  it  includes  the  standard 
Boolean  connectors  — .,  a,  v,  =>,  T  and  F.  The  notation  P  1=  A  means  that  CCS  agent  P 
satisfies  the  HML  assertion  A. 

HML  is  also  a  modal  logic,  able  to  express  assertions  that  are  possibly  true  or 
necessarily  true.  It  includes  modal  quantifiers.  Angle  brackets  denote  possibility  and 
square  brackets  denote  necessity.  These  brackets  enclose  actions  or  sets  of  actions.  Thus 
the  notation  P  1=  \ci]A  means  that  for  every  a  action  that  agent  P  can  perform,  the 
successor  agent  P'  A.  Note  that  if  P  cannot  perform  such  an  a  action  then  P  1=  \a\A 
is  vacuously  true.  P  —  <a>A  means  that  there  is  at  least  one  a-action  that  P  can  do  such 
that  the  successor  P'  1=  A.  The  special  identifier  denotes  the  entire  set  of  actions. 
Thus  P  1=  [~]A  means  that  every  action  performable  by  P  results  in  an  agent  satisfying  A. 

HML  gives  the  ability  to  define  and  check  properties  of  agents  on  the  CWB.  First 
note  that  all  agents  satisfy  the  trivial  assertion  T  (truth).  One  can  construct  the  assertion 
E  1=  <->T  which  says  that  there  is  some  action  that  agent  E  can  perfonn  and  evolve  to 
something.  In  other  words,  E  can  perform  some  action  and  is  therefore  live.  Conversely, 
E  1=  [-J/7  says  that  E  cannot  do  any  action  and  is  therefore  deadlocked.  Thus  the  CWB 
provides  a  means  of  defining  and  checking  properties  such  as  deadlock  and  liveness. 

2.5.2  Fixed  Points.  For  the  modeling  of  digital  hardware  one  generally  desires 
reactive  agents  that  operate  indefinitely,  continually  returning  to  a  “ready”  state.  In  other 
words,  the  most  interesting  agents  are  recursive.  Thus,  interesting  propositions  about 
such  agents  will  also  be  recursive.  To  handle  such  recursive  propositions,  HML  is 
augmented  with  the  ability  to  handle  fixed  points.  The  result  is  the  modal  //  calculus 
(Stirling,  1992).  Consider  again  the  recursive  C  element: 
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(2-14) 


C  =  a.b.c.C+b.a.c.C 

A  property  one  might  suspect  for  the  C  element  is  that  any  output  action  c  is  preceded 
by  exactly  two  input  actions.  Thus: 

C  (=  <-><-><  c>T 

C  t=  <-><-><  c  ><-><-><  c>T 

C  t=  <-><-><  c  ><-><-><  c  ><-><-><  c  >T 

C  b=  <-><-><  c  ><-><-><  c  ><-><-><  c  ><-><-><  c  >T  (2- 

15) 

and  so  on.  This  sequence  suggests  a  more  compact,  single  assertion: 

X  \=  <-><-><  u>X  (2-16) 

Such  a  fonnula  is  a  recursion  of  the  fonn  X  =  F(X).  A  set  of  system  states  X  that  can 
satisfy  this  recursive  assertion  is  called  a  fixed  point  solution  because  it  is  unaffected  by 
repeated  applications  of  F.  There  may  very  well  be  more  than  one  set  of  states  that 
qualifies  as  a  fixed  point  solution.  These  solution  sets  are  partially  ordered  under  the 
subset  relation  <z.  The  smallest  such  set  is  called  the  minimum  fixed  point.  It  contains 
only  those  states  for  which  the  assertion  is  necessarily  true.  The  largest  such  set,  the 
maximum  fixed  point,  includes  all  states  except  those  for  which  the  assertion  is 
necessarily  false.  The  minimum  and  maximum  fixed  points  of  the  formula  X  =  F(X)  are 
denoted  min(X.F(X ))  and  max(X.F(X)),  respectively. 
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2.5.3  Temporal  Logic.  A  class  of  logics  called  temporal  logics  “defines 
predicates  over  infinite  sequences  of  states”  of  systems  as  they  evolve  over  time  (Manna 
and  Pnueli,  1992:179).  The  modal  p  calculus  qualifies  as  a  temporal  logic.  However, 
the  complicated  fixed  point  notation  of  the  modal  p  calculus  can  be  very  difficult  to 
follow.  A  refinement  to  the  calculus  defines  certain  temporal  operators  which  amount  to 
a  shorthand  for  more  extensive  modal  p  fixed  point  fonnulas.  These  operators  have 
simple  English  interpretations.  The  operator  can  be  read  as  “always.”  It  precedes  an 
assertion  that  is  guaranteed  to  hold  at  all  future  times,  regardless  of  how  the  behavior 
may  branch.  P  t=  E  means  that  E  holds  for  all  future  successors  to  agent  P.  Read  as 
“always  E ,”  E  is  easier  to  interpret  than  the  more  ungainly  max{X  =  E  a  [-]A).  The 
diamond  operator,  0,  denotes  possibility.  P  (=  0£  means  that  there  is  some  execution 
sequence  for  which  at  least  one  successor  satisfies  E.  The  operator  EV  denotes 
eventuality.  P  1=  EV  E  means  that  along  all  execution  branches,  sooner  or  later,  a 
successor  agent  will  be  encountered  which  satisfies  E. 

These  convenient  operators  can  be  defined  as  macros  in  the  CWB.  Conventional 
usage  defines  the  macros:  BOX,  POSS,  and  EV  to  denote  the  operators:  ,  0,  and  EV, 
respectively.  Liu  has  shown  how  this  calculus  can  be  used  to  check  for  specification 
properties  on  the  CWB  (Liu,  1992).  The  C  element,  for  example,  should  satisfy  the 
property  that,  after  both  inputs  a  and  b  have  been  received  the  only  possible  move  is  an 
output  c.  Liu  has  built  a  macro  called  ONLY'c  defined  as  meaning  <c>  &  [- c  ]F 
(“You  can  always  perfonn  c  but  nothing  else  is  possible”).  Applied  to  the  C  element, 
Liu  derives  the  specification 

(  [a][b]  ONLY’c  )  &  (  [b][a]  ONLY’c  )  (2-17) 
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which  literally  says  that  it  is  always  the  case  that  every  time  a  is  followed  by  b,  or  b  by  a, 
the  only  possible  action  is  an  output  c  . 

2.6  Coinduction  and  Transition  Induction 

Since  recursive  CCS  agents  never  halt,  such  agents  produce  action  streams  that 
are  infinite  in  extent.  These  streams  can  be  observed  from  one  end  by  unwinding  the 
agent  definition.  However,  one  could  never  proceed  to  construct  such  a  stream  from  the 
empty  sequence  s.  The  fixed  point  approach  presented  above  allows  one  to  reason  about 
these  infinite  streams.  Modal  and  temporal  logics  which  incorporate  fixed  point 
reasoning  can  be  automated  by  tools  such  as  the  Concurrency  Workbench  to  reason  about 
recursive  agents. 

For  manual  proofs,  a  technique  called  coinduction  is  employed  to  reason  about 
infinite  streams  and  recursive  processes  (A.  Gordon,  1995;  Rutten,  1996;  Jacobs  and 
Rutten,  1997;  Wegner  and  Goldin,  1999).  Coinduction  is  the  dual  of  the  more  familiar 
induction  technique.  Both  techniques  can  be  used  both  to  conduct  proofs  and  to  provide 
definitions.  The  differences  between  the  two  techniques  can  best  be  highlighted  by 
examining  how  (co)inductive  definitions  are  pursued. 

An  inductive  definition  consists  of  three  general  parts,  with  the  third  so  obvious 
that  it  is  usually  not  stated.  The  three  parts  of  an  induction  are:  (1)  the  basis,  (2)  the  set 
of  constructors,  and  (3)  the  principle  of  minimality.  The  basis  is  a  starting  point  from 
which  to  build  the  set  being  defined.  For  the  natural  numbers  N  the  basis  is  the  number 
0.  Constructors  are  means  to  build  other  members  of  the  defined  set.  A  single 
constructor  +  (or  alternately  the  successor  function  S(x)  =  x  +  1)  suffices  for  N.  The 
principle  of  minimality  asserts  that  nothing  else  fills  the  definition  except  what  can  be 
constructed  from  the  basis  via  the  constructors.  One  can  informally  state  the  inductive 
definition  of  N  as 
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Basis.  “0  is  a  natural  number.” 


Construction.  “Successors  of  natural  numbers  are  natural  numbers.” 

Minimality.  “Nothing  else  is  a  natural  number.” 

Coinduction  consists  of  two  parts  instead  of  three,  since  it  lacks  an  analog  for  the 
basis.  In  place  of  constructors,  coinduction  uses  observers — means  of  observing  the 
behavior  of  the  item  being  defined.  One  is  generally  unaware  of  the  structure  of  the 
entity  that  produces  said  behavior;  only  the  behavior  itself  is  accessible.  In  place  of 
minimality,  coinduction  uses  a  principle  of  maximality.  Whereas  minimality  forbids 
everything  that  cannot  be  constructed,  maximality  allows  everything  that  is  not  forbidden 
by  the  observations. 

Consider,  once  again,  the  C  element.  The  attempt  to  define  a  C  element 
inductively  will  fail.  One  might  propose  the  NIL  agent  as  a  basis  and  use  the  CCS 
operators  as  constructors;  but  one  cannot  build  a  recursive  agent  from  NIL.  Similarly, 
one  cannot  build  the  associated  infinite  action  streams  a,  b  and  c  by  construction  from  s. 
Rather,  one  has  only  the  recursive  behavior  of  C:  C  =  a.b.c.C  +  b.a.c.C.  An 
appropriate  observer  then  is  a  rule  that  accesses  the  head  of  the  behavior  and  defers  the 
evaluation  of  the  rest.  An  observer  function  may  look  something  like  this:  behavior(aJC) 
=  a.behavior{X).  Observers  can  be  applied  arbitrarily  many  times  to  unwind  more  and 
more  behavior,  but  the  end  of  the  behavioral  streams  can  never  be  reached.  The 
coinductive  definition  of  the  C  element  can  be  informally  stated  as 

Observation.  “The  C  element  can  perform  all  action  streams  that  unwind  from 
C  =  a.b.c.C  +  b.a.c.C." 

Maximality.  “Everything  consistent  with  this  observation  is  a  C  element.” 
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Coinductive  proof  can  appear  circular  and  unsatisfying  due  to  its  lack  of  a  basis 
step.  For  a  coinductive  proof  it  suffices  to  shown  that  a  single  unwinding  of  each 
observer  function  preserves  the  property  in  question.  For  CCS  agents,  the  CCS  transition 
rules  (Milner  1989:45,  57)  serve  as  observers,  and  proofs  of  properties  over  CCS  agents 
are  often  coinductions  employing  these  observers.  Milner  calls  such  coinductive  proof 
transition  induction  (Milner,  1989:58,  100)  and  reaches  conclusions  “by  induction.” 
Transition  coinduction  might  be  a  more  appropriate  term,  but  Milner’s  usage  predates  the 
general  recognition  of  coinduction  as  a  technique  distinct  from  induction. 

2. 7  Applying  Formal  Methods  to  VHDL 

This  section  presents  the  efforts  of  researchers  who  have  studied,  more 
specifically,  the  formal  verification  of  VHDL  models.  These  efforts  fall  into  two  general 
camps.  First  are  the  extraction  techniques  that  seek  to  recover  higher-order  function 
from  low  level  or  “flat”  models.  Extraction  includes  both  logic  extraction,  in  which 
high-order  structural  blocks  are  substituted  in  flat  structural  models,  and  temporal 
extraction,  where  a  more  general  model  of  behavior  is  substituted  for  a  collection  of 
simpler  behaviors.  The  second  camp  seeks  to  translate  between  VHDL  and  other 
languages  or  tools  so  that  the  power  of  those  tools  will  accrue  to  VHDL  models.  In  the 
second  camp,  an  understanding  and  defining  of  VHDL  semantics  is  essential. 

2.7.1  Extraction.  The  extraction  process  is  one  of  iterative  substitution  using 
templates.  The  extractor  repeatedly  examines  a  flat  design  for  subunits  that  match  some 
template.  Whenever  such  a  match  is  found,  those  subunits  are  deleted  and  replaced  with 
a  single,  equivalent,  higher-level  unit  as  dictated  by  the  template.  For  example,  one 
knows  (or  at  least  believes)  that  three  NAND  and  two  XOR  gates,  when  connected  as 
shown  in  Figure  2-2,  will  create  a  one -bit  full  adder.  Similarly,  eight  full  adders  in 
cascade  will  form  a  byte-wide  adder.  By  such  repeated  substitution,  one  may  find  that  a 
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Figure  2-2.  Full  Adder 

network  of  interconnected  gates  can  be  transformed,  say,  to  a  32-bit  ALU.  Extraction 
thus  serves  as  a  verification  that  the  original  flat  design  is  “equivalent”  to  the  32-bit 
ALU.  Extraction  presumes  that  the  equivalence  notion  used  to  govern  the  substitutions  is 
in  fact  a  congruence. 

2. 7. 1.1  Logic  Extraction  with  VHDL.  Dukes  applied  the  process  of  logic 
extraction  to  VHDL  models  in  the  development  of  his  Generalized  Extraction  System 
(GES)  (Dukes,  1993).  The  extraction  process  itself  is  only  as  accurate  as  the  templates 
used.  Dukes  realized  that  in  a  controlled  VHDL-based  design  environment  where  the 
design  library  itself  was  developed  and  documented  with  VHDL,  there  was  no  need  to 
produce  these  templates  manually.  Rather,  extraction  templates,  or  extraction  rules  could 
be  automatically  derived  from  VHDL  structural  models  of  library  components.  His  GES 
system,  written  in  Prolog,  would  first  derive  appropriate  extraction  rules  from  VHDL 
models  or  the  technology  design  library,  and  then  apply  those  rules  to  perform 
extractions  on  circuits  designed  in  that  technology. 

One  limitation  of  Dukes’  technique,  and  indeed  of  logic  extraction  in  general,  is 
the  strict  dependence  on  structural  templates.  It  does  not  seek  to  establish  the  behavioral 
equivalence  of  models.  Even  when,  as  with  GES,  the  extraction  rules  are  derived  from  a 
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design  library,  the  extraction  system  takes  for  granted  the  library  designer’s  claim  that, 
for  example,  “these  five  gates  are  equivalent  to  one  full  adder.”  It  assumes  a  behavioral 
equivalence  between  the  gates  and  their  purported  function.  Hopefully,  library  units  will 
have  been  independently  and  exhaustively  verified.  For  a  component  as  simple  as  a  five 
gate  device,  this  is  probably  true.  However,  one’s  confidence  becomes  less  certain  as 
when  moving  up  in  complexity. 

Dukes’  tool  reacts  only  to  structural  VHDL  constructs.  Any  behavioral 
constructs,  such  as  a  process  statement  or  an  assert,  is  ignored.  Thus,  GES  and  logic 
extraction  in  general,  will  not  verify  a  design  against  some  purely  behavioral  device 
model,  nor  will  it  verify  that  logical  conditions  are  met. 

2. 7. 1.2  Temporal  Extraction.  Fujita  developed  a  Prolog-based  temporal 
extractor  (Fujita  and  others,  1983;  1983a).  This  tool  extracts  and  verifies  temporal 
formulas  using  the  “temporal  logic  decision  procedure”  developed  by  Wolper 
(Wolper,  1981).  Thus,  Fujita’s  tool  is  a  behavioral  extractor,  in  contrast  to  Dukes’ 
structural  extraction  system.  Fujita  aimed  to  verify  that  a  collection  of  behaviors  of 
some  circuit  would  satisfy  some  desired  “protocol”  (in  other  words:  “higher-level 
behavior”). 

Fujita  notes  that,  in  general,  the  satisfiability  of  temporal  formulas  is  undecidable. 
However,  he  draws  on  Wolper’ s  method,  which  uses  rewrite  rules  based  on  a  right-linear 
grammar.  Wolper  had  14  such  rules,  which  tend  to  transform  other  temporal  operators 
into  next  operators,  ‘O’,  and  then  migrate  these  operators  to  the  left  of  the  formula.  At 
any  instant  in  time  Wolper  needed  only  to  deal  with  ‘O’  since  any  other  temporal 
operator  would  be  embedded  within  the  formula,  to  eventually  pop  out  as  ‘O’  anyway. 
Thus,  instead  of  dealing  with  the  undecidability  associated  with  infinite  sequences  of 
states,  Wolper’s  method  looked  forever  at  only  the  “next”  state  or  event.  Note  how  this 
quite  naturally  mimics  the  YHDL  simulation  engine,  wherein  the  simulator  focuses  on 
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the  next  scheduled  event,  ignoring  any  other  transactions  until  they  in  turn  become  the 
“next  event.” 

Fujita’s  reliance  on  the  Wolper  procedure  means  that  his  method,  when  applied  to 
VHDL,  only  captures  its  simulation  semantics.  Furthermore,  just  as  logic  extraction 
compares  only  structural  models,  Fujita’s  temporal  extraction  technique  compares  only 
behavioral  models.  Needed  is  a  method  of  verifying  a  structural  model  against  a 
behavioral  model. 

2.7.2  Semantic-based  Approaches.  Extraction  is  a  clever  tool  for  manipulating 
models.  However,  this  template -based  approach  relies  on  syntactic  substitutions.  When 
applied  to  YHDL  models,  it  makes  no  use  of  what  the  YHDL  language  actually  means  in 
tenns  of  the  performance  of  real  hardware.  To  perform  verifications  between  behavioral 
and  structural  models,  one  needs  a  fonnalization  of  the  semantics  of  VHDL.  These 
semantics  need  to  be  based  on  some  logic  to  allow  rigorous  verification  by  formal  proof. 

Auletta  devised  a  translation  from  a  restricted  subset  of  the  process  algebra  CSP 
to  VHDL  (Auletta,  1991).  In  performing  the  translation,  he  strove  for  synthesizable 
VHDL,  meaning  models  of  finite  state  machines  in  the  register  transfer  logic  ( RTL )  style. 
One  semantic  mismatch  he  noted  was  that  while  CSP  allowed  the  expression  of  non¬ 
determinism,  VHDL  did  not.  To  cope  with  this  non-detenninism  when  translating  to 
VHDL  he  used  a  “scheduling  mechanism.”  This  insight  into  how  VHDL  might  model 
indeterminism  is  enlightening.  However,  for  this  dissertation,  the  reverse  translation,  i.e., 
from  VHDL  to  CSP  (or  similar  algebra)  is  viewed  as  the  more  interesting.  CCS  makes  a 
better  target  algebra  anyway.  CSP  is  inadequate  for  dealing  with  many  concurrency 
issues,  due  to  its  inability  to  express  internal  action.  CSP  requires  mutual  simultaneous 
agreement  between  processes  for  communication  to  occur.  Whereas  problems  such  as 
deadlock  occur  when  there  is  no  such  agreement,  a  deadlocking  process  waits  forever  on 
data  that  will  never  be  sent. 
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Van  Tassell  (van  Tassel,  1994)  defined  a  formal  semantics  for  a  limited  subset  of 
VHDL  using  the  language  Higher  Order  Logic  (HOL)  (M.  Gordon,  1987;  1992).  His 
“nano-VHDL”  is  a  very  restricted  subset  of  VHDL  that  captures  the  basic  VHDL 
semantics.  Using  HOL,  van  Tassell  wrote  abstract  syntax  to  formally  define  the 
semantics  of  a  limited  number  of  VHDL  constructs.  He  then  used  the  HOL  proof 
assistant  to  perform  symbolic  simulations  on  the  resulting  HOL  models.  Limitations  of 
van  Tassel’s  work  are:  (1)  the  subset  is  extremely  small,  (2)  the  translation  from  VHDL 
to  HOL  is  manual,  and  (3)  he  fonnalizes  the  simulation  engine  of  the  VHDL  LRM,  such 
that  his  semantics  are  insensitive  to  internal  action  and  cannot  embody  the  properties 
desired  to  establish  safe  substitution  and  to  detect  deadlock  and  other  invariants. 

Jamsik  and  Bickford  used  a  logic-based  approach  to  formalizing  the  semantics  of 
VHDL  (Jamsik  and  Bickford,  1994).  This  model  checking  approach  uses  a  family  of 
formal  specification  tools  and  languages  referred  to  collectively  as  Larch  (Guttag  and 
Homing,  1993).  In  this  approach,  VHDL  entities  are  modeled  (quite  naturally)  in  VHDL. 
Requirements  or  specifications  are  written  in  a  special  requirements  language  called  a 
Larch  Interface  Language,  or  LIL.  A  different  LIL  is  generated  for  each  target  language. 
VHDL-LIL  statements  are  embedded  as  comments  called  annotations  in  the  VHDL  code. 
This  results  in  judgments,  which  are  logical  statements  to  the  effect  that  an  entity  E 
satisfies  a  requirement  (p.  These  judgments  are  then  proven  with  the  aid  of  a  set  of 
axioms  and  inference  rules  governing  judgments. 

Jamsik  and  Bickford  separate  out  requirements  as  annotations  from  the  behavioral 
model,  the  VHDL  top-level  behavioral  model  itself.  Their  work  expresses  a  general 
logic-based  semantics  not  limited  to  a  simple  formalization  of  the  simulation  semantics. 
However,  their  annotations  appear  to  be  limited  to  properties  incumbent  on  named 
signals.  It  is  not  apparent  how  certain  concurrency  properties  not  tied  to  a  specific  signal, 
such  as  freedom  from  deadlock,  can  be  expressed,  if  indeed  they  can. 
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Hua  and  Zhang  (Hua  and  Zhang,  1993)  translated  YHDL  into  a  formal  logic  and 
used  theorem  proving  for  verification.  Their  tool,  VAT  (VHDL  to  Algebraic 
Translator),  turns  VHDL  into  RRL  (Rewrite  Rule  Laboratory)  syntax.  The  VAT 
translator  maps  structural  VHDL  into  RRL  axioms  and  maps  behavioral  VHDL  into  RRL 
theorems.  Hence  VAT  creates  an  axiomatic  system  based  on  the  hardware 
implementation,  and  the  specification  is  thus  a  set  of  theorems  to  be  proved  about  the 
hardware. 

The  VAT  approach  is  very  similar  to  one  goal  of  the  present  research,  i.e.,  to 
forge  a  semantic  link  between  VHDL  and  some  logic.  However,  the  work  is  limited  to  a 
“significant  subset”  of  VHDL,  and  the  hardware  verified  must  be  in  the  synchronous 
design  style.  Of  course,  the  synchronous  design  style  is  very  widely-used,  but 
asynchronous  design  is  more  fundamental,  and  concurrency  issues  are  more  likely  to 
arise  in  asynchronous  designs.  Furthermore,  Hua  and  Zhang’s  “significant  subset”  is  not 
a  proper  subset  of  VHDL.  They  invent  additional  VHDL  syntax  for  the  convenience  of 
the  VAT  tool.  They  add  the  symbol  «=  to  denote  connections  which  involve  feedback, 
and  the  keyword  algebraic  to  denote  the  expression  of  a  requirement.  Any  such 
decoration  of  YHDL  code  before  verification  ought  to  be  avoided  due  to  the  possible 
introduction  of  errors. 

Read  and  Edwards  (Read  and  Edwards,  1994)  translated  VHDL  to  Boyer-Moore 
logic.  Boyer-Moore  Logic  is  a  quantifier-free  first  order  logic  with  equality.  Its  syntax  is 
similar  to  LISP.  Their  translation  to  YHDL  works  in  two  stages: 

(1)  VHDL  syntax  is  mapped  to  Boyer-Moore  expressions. 

(2)  “Stage  2  is  an  operational  definition  of  a  VHDL  simulation  kernel.” 

Stage  (1)  has  the  happy  result  of  reducing  the  great  number  of  VHDL  constructs 
to  the  much  smaller  catalog  of  Boyer-Moore  functions.  Stage  (2)  creates  a  “formal 
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simulator  for  VHDL.”  These  researchers  too  have  formalized  the  simulation  semantics, 
rather  than  expressed  higher  semantics. 

Limitations  of  Read  and  Edwards’  technique  are  many.  First,  the  associated 
theorem  prover,  NQTHM,  is  ungainly.  It  is  not  fully  automated,  and  must  be  guided.  As 
a  result,  these  researchers  were  essentially  without  results.  They  attempted  one  small 
example,  but  then  stated  “the  equivalence  theorem  ...remains  unproved.”  They  also  note 
that  their  technique  “loses  instance  names.”  Multiple  architectures  of  a  single  entity  are 
known  by  the  entity  name.  The  architecture  name  is  thrown  away.  They  defend  this 
practice  by  stating  that  this  lack  of  differentiation  “maintains  the  association  between 
them.”  This  attitude  seems  very  naive.  Just  because  a  human  designer  creates  two 
architectures  which  he  believes  to  represent  the  same  entity  does  not  mean  they  actually 
are  equivalence,  congruent,  confonnant  or  anything.  This  is  why  one  verifies  designs  in 
the  first  place. 

Finally,  Read  and  Edwards  treat  variables  like  signals,  that  is,  their  tool  deletes 
any  indication  of  which  is  which.  Hence  when  assignments  are  made  to  variables,  their 
values  are  updated,  not  immediately,  but  only  after  the  simulation  clock  advances.  This 
is  a  serious  violation  of  the  VHDL  semantics! 

Examples  of  commercial  formal  verification  tools  for  VHDL  are  Abstract 
Hardware’s  CheckOff-M  and  CheckOff-E  (Musgrave  and  others,  1997).  CheckOff-E  is  a 
formal  equivalence  checker,  and  CheckOff-M  is  a  model  checker.  Both  provide  links 
from  VHDL  to  CIL,  a  restricted  form  of  the  temporal  logic  CTL  (Burch,  1989). 
CheckOff-M  in  particular  will  check  temporal  properties  of  behavioral,  RTL,  or 
structural  VHDL  models.  The  literature  provided  also  claims  that  concurrency  issues 
such  as  deadlock  and  race  can  be  detected.  However,  the  toolset  is  limited  to  the 
evaluation  of  deterministic  automata.  Therefore,  higher  equivalence  semantics  such  as 
bisimulation  are  indistinguishable  from  trace  equivalence. 
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Many  modem  “formal  verification”  tools  for  VHDL  were  displayed  at  the  2001 
Design  Automation  Conference.  These  providers  generally  add  the  VHDL  assert 
statement  to  models  to  force  the  gathering  of  statistics  during  simulation.  The 
characterization  of  this  technique  as  “formal  verification”  is  a  misnomer. 

2.8  Hardware  Order  Relations  and  Conformances 

A  major  goal  of  this  dissertation  is  to  establish  a  formal  conformance  relation  that 
accurately  captures  intuitive  notions  of  when  a  device  adheres  to  a  specification  model, 
or  when  a  part  of  unequal  capability  can  be  substituted  for  another  part.  This  relation,  to 
be  called  congruent  weak  conformance,  is  a  partial  ordering  among  hardware  agents. 
This  section  explores  other  such  asymmetric  process  ordering  relations  presented  in  the 
literature,  known  variously  as  preorders,  partial  orders  and  conformances .  Rather  than 
introduce  the  special  notation  for  each,  ‘>’  will  be  used  as  a  general  ordering  symbol. 

Arun-Kumar  presents  an  efficiency  preorder  (Arun-Kumar  and  Hennessy;  1992; 
Arun-Kumar  and  Natajaran,  1995).  An  efficiency  preorder  P  >  Q  requires  that  P  «  Q 
with  P  being  “faster  than”  or  “more  efficient  than”  Q.  This  speed  or  efficiency  is 
measured  by  the  amount  of  internal  computation  required.  In  essence  an  efficiency 
preorder  counts  z  actions.  Thus,  if  P  =S>  by  way  of  a  direct  A-  whereas  Qdf  via  -A 
then  P  is  faster  than  Q.  One  limitation  of  the  efficiency  preorder  is  the  assumption  that 
all  r  actions  have  unit  weight.  This  rough  measure  of  efficiency  is  often  not  realistic. 
Secondly,  the  efficiency  preorder  establishes  an  ordering  within  each  ^-equivalence 
class.  There  is  no  preorder  between  processes  that  are  not  observationally  equivalent. 
Hence  the  efficiency  preorder  does  not  model  the  compliance  of  an  implementation  to  a 
specification,  where  the  observable  behaviors  can  differ. 

A  related  concept  is  the  divergence  preorder  (Ingolfsdottir  and  Schalk,  1995).  A 
divergence  is  an  unending  chain  of  internal  computation,  such  as  in  D  =  z.D  +  a  .D, 
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where  z  can  execute  indefinitely  and  starve  a.D.  For  the  divergence  preorder,  P  >  Q 
when  P  «  Q  but  Q  may  diverge  more  than  P.  Like  the  efficiency  preorder,  the  divergence 
preorder  requires  observational  equivalence,  and  the  desired  implementation- 
specification  relation  is  not  modeled. 

A  faster-than  preorder  uses  an  extended  CCS  that  associates  worst-case  execution 
times  with  actions  (Luttgen  and  Vogler,  2001).  Thus  agents  can  possess  execution  times 
resembling  real  operation.  The  faster-than  preorder  is  again  an  ordering  among 
^-equivalent  agents  and  does  not  capture  the  desired  compliance  ordering  among 
specifications  and  implementations. 

Some  researchers  take  note  that  the  transition  graph  of  a  process  creates  an 
ordering  among  its  derivatives  (Godefroid,  1995;  Alur  and  others,  1997;  Corradini  and 
others,  1997;  Degano  and  Priami,  1999).  Thus  if  a  transition  P=>Q  exists  then  P  >  Q. 
This  can  be  called  a  causal  of  derivational  preorder.  Intuitively,  these  processes  are 
understood  to  be  ordered  by  priority  of  occurrence.  Again,  this  causal  preorder  does  not 
capture  the  desired  implementation-to-specification  relationship,  where  I>  S  should 
apply  at  instants  of  time. 

Segala  presents  a  quiescent  preorder  over  processes  (Segala,  1994).  It  compares 
only  quiescent  states — those  that  only  accept  inputs — and  is  undefined  over  the  many 
intennediate  states  capable  of  output  or  internal  action.  Segala  shows  that  the  quiescent 
preorder  is  substitutable,  and  therefore  a  congruence.  However,  since  only  quiescent 
states  are  compared,  he  side-steps  the  issue  of  initial  instability,  which  can  affect 
congruence  (Milner,  1989:112).  The  “greater”  (left-hand)  process  can  possess 
unspecified  output  pins.  This  dissertation  calls  such  excess  pins  extraneous.  The 
quiescent  preorder  handles  extraneous  outputs  by  hiding  them  prior  to  any  attempt  to 
compare  agents.  This  simplifies  the  analysis,  but  loses  the  fact  that  the  extraneous  action 
set  can  change  depending  on  which  two  models  are  compared.  Finally,  all  required 
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outputs  must  be  “yielded”  by  the  implementation,  so  the  quiescent  pre-order  does  not 
exploit  output  concurrency. 

Preorders  have  also  been  defined  based  on  testing  semantics  (Hennessy, 
1988:Chapter  2).  A  test  is  a  sequence  of  input  and  output  actions  where  the  inputs 
become  stimuli  for  the  device  under  test,  and  the  outputs  denote  expected  responses.  If 
the  expected  responses  are  achieved,  the  device  or  model  passes  the  test.  Possible  non- 
deterministic  execution  is  allowed  via  may  and  must  testing.  A  process  P  may  pass  test  e 
if  P  has  an  execution  path  that  passes  e.  Other  paths  that  fail  e  are  allowed.  P  must  pass 
e  when  there  are  no  executions  for  which  it  would  fail.  The  may  and  must  preorders  are 
defined  in  terms  of  test  set  containment.  Hence  P  <may  Q  if  {e  :  P  may  satisfy  e}  c:  {e  :  Q 
may  satisfy  ej  with  a  similar  definition  for  <must. 

def 

Consider  whether  testing  preorders  can  be  used  to  express  compliance.  Let  S  = 
a.(o.p  +  p.o ).  S  has  an  output  concurrency  permitting  o  and  p  to  occur  in  either 
order.  Let  /  =  a.o.p  .  I  complies  with  S  by  having  selected  one  output  interleaving. 
The  set  of  tests  that  S  may  pass  is  {  a.o.p  ,  a. p.o  } .  For  /,  that  set  is  { a.o.p  } ,  so  /  <may  S. 
The  set  of  tests  that  S  must  pass  is  empty,  whereas  the  must  pass  set  for  /  is  { a.o.p  } . 
Hence  S  <must  I.  One  might  suppose  that  /  <may  S  <must  /  denotes  the  proper  compliance 
relationship.  Yet  NIL  <may  S  <must  NIL  and  NIL  is  not  compliant  to  S.  One  concludes  that 
the  testing  preorders,  as  defined,  do  not  support  the  expression  of  compliance. 

Conformances  are  asymmetrical  relations  with  the  specification  appearing  on  the 
right  and  the  implementation  on  the  left.  Stevens  studied  conformances  and  developed  a 
new  property  called  logic  conformance  (Stevens,  1994:136-44). 
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Definition  2-6.  (Stevens,  1994:  Definition  30).  Implementation  I  logically  conforms  to 
specification  S,  written / >-  S,  iff  Va  e  Act,  V/?  e  4u{x}  and  Vye  yt 

(1)  Whenever  S-^-S'  then  for  some  /' :  /'  and  /'  S" 

(2)  Whenever  /A/'  then  for  some  S"  :  S^>  S'  and  I' >j  S' 

(3)  Whenever  /^»  /'  and  S’  =>  then  for  some  S' :  S^>  S'  and  /'  y,  S' 

Logic  confonnance  respects  preemptive  internal  actions  and  abstract  away  all  others.  It 
is  sensitive  to  the  branching  structure  of  agents.  It  detects  deadlock,  and  requires  that 
deadlocks  in  the  implementation  must  match  deadlocks  in  the  specification.  Part(l) 
contains  the  basic  demand  that  all  specified  behaviors  be  implemented.  Part  (2)  demands 
that  every  implemented  output  correspond  to  a  specified  output  event.  In  part  (3),  the 
additional  premise  S^  allows  the  implementation  to  accept  unspecified  inputs. 

Confonnances  treat  input  and  output  distinctly.  Hence,  for  confonnance 
relations,  the  overbar  is  identified  specifically  with  output.  This  departs  from  previous 
usage,  where  the  overbar  is  used  merely  for  synchronization,  and  the  association  with 
either  input  or  output  is  arbitrary.  The  association  of  the  overbar  strictly  with  output  is 
enforced  throughout  the  remainder  of  this  dissertation. 

Logic  confonnance  has  shortcomings  that  need  remedy.  First  of  all,  part  (1)  is 
overly  restrictive  with  respect  to  outputs.  It  requires  /  to  implement  every  specified 
output  action,  even  when  there  is  output  concurrency.  Secondly,  part  (2)  makes  no 
allowance  for  the  implementation  to  generate  output  signals  outside  of  the  specification. 

2.9  Summary 

This  chapter  discussed  various  verification  methods,  introduced  the  concept  of 
process  algebra,  and  outlined  the  process  algebra  CCS.  CCS  was  then  used  as  a  tool  to 
discuss  the  differentiation  of  various  hardware  equivalences,  of  which  four  were 


2-31 


presented.  Modal  and  temporal  logics  were  presented  as  a  means  to  assert  requirements 
on  hardware  models  written  in  some  process  algebra. 

Section  2.7  then  considered  how  formal  verification  methods  have  been  applied  in 
the  past  to  VHDL  models.  Extraction  techniques,  which  are  purely  syntactic,  were  first 
presented,  followed  by  several  semantic -based  approaches.  Limitations  of  past 
techniques  include: 

(1)  Inability  to  compare  structure  to  behavior. 

(2)  Fonnalization  of  the  VHDL  simulation  semantics  only. 

(3)  Severely  limited  VHDL  subset. 

(4)  Artificially  created  additional  VHDL  syntax. 

(5)  Requirement  to  manually  edit  or  annotate  VHDL  code  prior  to  verification. 

(6)  Oversimplification  of  the  semantics.  (For  example,  treating  variables  and 
signals  as  the  same.) 

Section  2.8  presented  various  ordering  relationships  that  are  potential  competitors 
to  congruent  weak  conformance.  Limitations  of  these  techniques  include: 

(1)  The  ordering  is  not  based  on  compliance,  but  some  other  measure. 

(2)  The  ordering  is  applied  within  ^-equivalence  classes  only. 

(3)  The  ordering  is  not  defined  for  all  states. 

(4)  The  ordering  does  not  allow  output  concurrency  options. 

Subsequent  chapters  will  describe  the  output  of  the  present  research  which  seeks 
to  alleviate  some  of  the  above  limitations. 
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III.  Weak  Conformations 


This  chapter  develops  the  precursor  relations  called  weak  conformations.  First,  a 
simple  example  is  given,  using  the  representational  power  of  CCS  to  exhibit  a 
specification  and  a  compliant  implementation.  The  example  yields  intuition  from  which 
the  four  transitional  laws  governing  weak  conformations  are  derived.  Extensive  formal 
results  are  derived  for  these  precursor  properties. 

3.1  Compliance  Example 

Consider  a  circuit  specified  to  convert  binary-coded-decimal  (BCD)  to  pure 
decimal.  It  takes  four  bits  to  encode  a  decimal  digit,  so  the  converter  will  have  four 
inputs,  one  for  each  of  the  encoding  bits.  Call  the  inputs  a,  b,  c  and  d.  The  ten  outputs 
will  be  labeled  do,  dj,...,  dg,  one  for  each  decimal  digit  detected.  One  can  think  of  the 
outputs  as  ten  indicator  lights.  In  a  CCS  model  of  the  specification,  each  time  there  is 
change  on  an  input  bit,  one  of  the  output  lights  turns  on  and  another  is  extinguished. 
Since  CCS  models  transitions  and  not  level  signals,  there  will  be  two  output  transitions 
concurrently,  but  it  will  not  be  readily  apparent  which  is  turning  on  and  which  is  turning 
off.  Assume  the  parent  system  does  not  care  if  momentarily  two  are  lit,  or  none.  The 
specification  will  allow  either.  The  specification  model  will  have  ten  named  states 
corresponding  to  each  decimal  digit.1  The  specification  model  is  identified  with  the  root 
state,  corresponding  to  decimal  zero: 


1  It  is  convenient  to  name  10  of  the  states,  but  the  model  has  many  more  intermediate  states.  There  is  a 
state  after  the  occurrence  of  each  atomic  action. 
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(3-1) 


S  =  SO  =  a.(do.di.Sl  +  di.do.Sl) 

+  b.{  do.02.S2  +  02.do.S2 ) 

+  c.(  do.d4.S4  +  d4.do.S4 ) 

+  d.(  do.ds.S8  +  d8.do.S8 ) 

Similar  definitions  exist  for  states  SI  through  S9.  However  the  code  is  ungainly  because 
two  terms  have  to  be  presented  each  time  there  is  concurrency  on  two  outputs.  The 

shorthand  notation  (do  \  di )  can  now  be  used  to  express  the  concurrency  of  output  signals 

2 

while  economizing  on  the  code. 


SO 

def 

a.( 

do 

di).Sl 

+ 

b.( 

do 

d2).S2 

+ 

c.( 

do 

o4).S4  + 

d.(  00 

ds).S8 

SI 

def 

a.( 

oi 

d0).  SO 

+ 

b.( 

oi 

o3).S3 

+ 

c.( 

oi 

d5).S5  + 

d.(  di 

d9).S9 

S2 

def 

a.( 

02 

d3).S3 

+ 

b.( 

02 

do).  SO 

+ 

c.( 

02 

d6).S6 

S3 

def 

a.( 

03 

d2).S2 

+ 

b.( 

03 

di).Sl 

+ 

c.( 

03 

o7).S7 

S4 

def 

a.( 

04 

o5).S5 

+ 

b.( 

04 

d6).S6 

+ 

c.( 

d4 

o0).  SO 

S5 

def 

a.( 

05 

o4).S4 

+ 

b.( 

05 

0t).S7 

+ 

c.( 

05 

di).Sl 

S6 

def 

a.( 

06 

07).S7 

+ 

b.( 

06 

o4).S4 

+ 

c.( 

06 

d2).S2 

S7 

def 

a.( 

07 

o6).S6 

+ 

b.( 

07 

o5).S5 

+ 

c.( 

07 

03). S3 

S8 

def 

a.( 

08 

o9).S9 

+ 

d.( 

08 

do).  SO 

S9 

def 

a.( 

09 

d8).S8 

+ 

d.( 

09 

di).Sl 

Only  states  SO  and  SI  respond  to  all  four  inputs  because  combinations  above  1001  are 
illegal  under  the  BCD  code.  Omitting  these  transitions  in  S2  to  S9  constitutes  the 
specification’s  guarantee  that  the  illegal  input  combinations  will  not  be  received. 


2  This  shorthand,  which  one  can  think  of  as  a  “parallelism  of  actions,”  is  not  part  of  the  CCS  formal 
syntax. 
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Given  the  above  specification  S,  what  sort  of  circuit  would  make  a  conforming 
implementation?  A  4:16  demux,  as  shown  in  Figure  3-1,  is  an  obvious  choice.  The 
inputs  a,  b,  c,  and  d  form  the  four  select  lines  of  the  demux.  Of  the  16  outputs,  only  10 
are  used,  and  six  are  left  unconnected.  A  fifth  input  pin  represents  the  multiplexed  input. 
In  this  application  that  pin  is  tied  to  ‘1’.  Note  therefore  that  a  compliant  implementation 
must  have  a  pin  for  every  I/O  pin  called  out  by  the  specification,  though  it  may  have 
more. 


o„ 


Figure  3-1.  4:16  Demux 

A  “first  cut”  CCS  model  for  this  demux  could  read  just  like  the  specification 
model  but  with  the  missing  input  transitions  added  and  the  extra  outputs  generated. 

I  =  10  =  a.{  do  |  di).Il  +  b.{  do  \  02)12  +  c.(  do  \  04)14  +  d.{  do  \  ds).I8 

def 

II  =  a.(  Oi  |  Oo).I  +  b.(  0 1  |  03)13  +  C.(  O;  |  05)15  +  d.(  0;  I  Og)19 

def 

19  =  a.(  do  |  08)18  +  b.(  dg  \  du)lll  +  c.(  dg  \  013)  113  +  d.{  dg  \  dj).Il  (3-3) 
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This  implementation  has  more  states  than  the  specification  due  to  its  ability  to 
execute  illegal  sequences.  Indeed,  this  is  allowable  since  the  specification  guarantees 
that  these  additional  states  are  unreachable.  One  might  hastily  conclude  that 
implementations  must  duplicate  all  the  states  of  the  specification,  with  additional  states 
allowed.  Yet  this  is  not  the  case.  Though  the  example  implementation  /  gratuitously 
generates  all  the  possible  output  interleavings  allowed  by  S,  in  reality  it  would  be  both 
difficult  and  counterproductive  to  create  such  a  device.  A  real,  physical  layout  results  in 
finite  delays  along  various  paths.  Most  likely,  the  same  interleaving  appears  every  time 
in  a  physical  implementation,  especially  when  the  delays  are  due  solely  to  passive 
components. 

Consider  a  diagram  of  the  transitions  from  SI  to  S2  (Figure  3-2).  Concurrency  of 
outputs  is  represented  by  a  characteristic  diamond  shape.  Clearly,  the  implementation 
need  only  navigate  one  path  through  this  diamond,  or  through  any  such  output  “burst.” 
The  same  is  not  true  for  inputs.  When  an  input  concurrency  is  present,  as  in  the  case  of 
the  C  element  (Equation  2-1),  the  implementation  must  remain  poised  to  accept  any 
possible  interleaving  that  may  come  and  therefore  must  be  able  navigate  all  paths  through 
a  specified  input  burst. 


SI 


a 

▼ 


S2 

Figure  3-2.  Output  Concurrency  Diamond 
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To  exploit  this  allowance  to  chose  among  output  interleavings,  a  “second  cut” 
implementation  J  chooses  specific  output  interleavings  where  possible.  This 
implementation  might  look  something  like  this: 

J  =  JO  =  a.do.diJl  +  b.do.d2.J2  +  C.O4.O0J4  +  d.Oo.ds.J8 

(3-5) 


and  so  forth.  One  specific  interleaving  is  chosen  at  each  output  concurrency. 

Thus  when  presented  with  an  output  concurrency,  the  implementation  can 
implement  any  or  all  the  paths,  as  long  as  at  least  one  path  is  implemented.  If  one 
considers  the  possible  paths  to  form  a  set,  then  the  implementation  must  select  some  non¬ 
empty  subset.  This  idea  will  be  captured  later  by  the  notion  of  maxoctset. 

Consider  now  the  question  of  behaviors  or  sequences  of  actions.  /  and  J  do 
accept  more  input  behaviors  than  S  specifies  due  to  their  ability  to  decode  illegal,  non- 
BCD  inputs.  However,  they  could  be  faulty  for  codes  ‘11’  through  ‘15’  and  still  function 
as  BCD  converters.  These  behaviors  are  irrelevant.  Designers  will  exploit  this  “don’t 
care”  region  of  behavior  to  produce  more  efficient  designs. 

In  this  example  neither  S  nor  its  implementations  /  and  J  contain  internal  action  z. 
These  models  are  strictly  behavioral,  and  hidden  actions  usually  arise  in  structural 
models,  where  there  can  be  communication  between  internal  signals.  Unlike  /  and  J, 
most  implementation  models,  in  practice,  will  be  structural;  and  a  structural  model  with 
no  internal  communication  is  a  rarity.  Therefore,  z  actions  in  the  implementation  are 
virtually  inevitable. 

Furthermore,  z  actions  in  the  specification  are  likely  as  well.  Some  practitioners 
advocate  that  complex  specification  models  be  presented  structurally  (Stevens  and  others, 
1993).  For  complex  behavior,  a  purely  “flat”  specification  model  will  have  an 
overwhelming  number  of  states.  Breaking  the  model  into  a  few  parallel  models  can 
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greatly  simplify  the  expression  of  the  specification,  though  they  can  introduce  r  in  the 
specification. 

The  BCD  decoder  example  shows  how  a  compliant  implementation  can  exceed 
the  specification  in  the  number  of  I/O  pins,  and  can  also  generate  illegal  behavior  in  the 
unreachable  state  space.  In  general  the  implementation  can  possess  more  behaviors  than 
the  specification,  though  it  can  get  by  with  fewer  output  behaviors.  In  the  next  section, 
the  intuition  derived  from  this  example  will  be  developed  formally,  yielding  a  set  of 
properties  called  weak  conformations.  Weak  conformations  are  precursor  properties  to 
the  target  relation  to  be  called  congruent  weak  conformance. 

3.2  Notation 

To  transform  intuitive  ideas  on  compliance  into  formal  properties,  additional 
symbolism  is  needed. 

First  of  all,  the  notion  of  sort  used  here  differs  from  Milner’s  usage.  Milner  uses 
syntactic  sorts  where  here  semantic  sorts  are  more  useful.  To  derive  a  syntactic  sort,  one 
simply  catalogs  the  symbols  appearing  in  the  expression  of  an  agent  and  its  derivatives. 
Some  of  these  symbols  may  in  fact  be  unreachable  from  the  root  state.  Since  they  will 
never  be  encountered,  they  are  excluded  from  the  semantic  sort.  The  efficiency  of 
deriving  semantic  sorts  is  not  an  immediate  concern  since  the  initial  intended  use  of 
congruent  weak  conformance  does  not  require  the  actual  generation  of  sorts  by  an 
automated  tool. 

Thus  L(P)  denotes  the  visible  semantic  sort  of  P.  Similarly,  JL(P)  and  J?  (P)  are 
the  semantic  input  and  output  sorts  of  P,  respectively,  with  JAct(P)  being  the  semantic 
action  set.  Note  that  JL(P)  u  A(P)  =  k(P)  c:  JLct(P)  and  that  although  JLctfP)  may 
include  r,  L(P),  JL(P)  and  JA  (P)  never  do. 

The  forward  slash  7’  denotes  “excess  of. ..over...”  for  strings  (Milner, 
1989:Definition  11.6).  Informally,  r/s  is  the  string  r  where  the  symbols  it  shares  with  s 
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have  been  removed.  This  removal  occurs  from  left  to  right  and  takes  note  of  the 
multiplicity  of  symbols  within  s.  Thus,  if  the  symbol  a  appears  twice  within  s  then  no 
more  than  two  occurrences  of  a  are  removed  from  r.  As  examples:  a.b.c/a.c  =  b, 
a.b.a.b/a  =  b.a.b,  and  a.b.c/a.a  =  b.c. 

‘  1  ’  denotes  the  projection  operation  and  normally  applies  to  the  projection  of  an 
action  string  onto  a  set.  Thus  t  \  MS)  is  the  string  t  with  all  actions  removed  except  those 
in  MS). 

A  new  notation  denotes  the  additional  pins  of  an  implementation  that  exceed 
those  of  the  specification.  These  are  called  extraneous  pins.  Pytr  (I,S)  is  the  set  of 

extraneous  output  of  /  with  respect  to  S,  and  (Exft{I,S)  the  extraneous  input  set. 


Definition  3-1.  Let  /  and  S  be  process  agents: 

(1)  ‘Extr(I,S)  =  MI)  ~  MS)  is  the  extraneous  input  sort  of  /  with  respect  to  S. 

(2)  cE.xtr  (I,S)  =  A  (I)  -  A(S)  is  the  extraneous  output  sort  of  /  with  respect  to  S. 

3.3  Weak  Confluence  and  Maxoctsets 

Weak  conformations  use  the  notion  of  confluence,  a  restricted  fonn  of 
determinism.  There  are  both  strong  and  weak  versions  of  confluence,  with  weak  being 
the  more  interesting.  One  of  Milner’s  results  will  serve  as  a  working  definition  of  weak 
confluence  (Milner  1989,  Proposition  11.11).  Shown  diagrammatically, 

Definition  3-2.  If  P  is  weakly  confluent  then 

r 

P^P' 

s  -U-  U ‘s/r 

P"^>* 

r/s 
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The  diagram  is  interpreted  such  that  the  top  and  left  transitions  imply  the  bottom  and 
right  transitions.  The  anonymous  successors  of  P'  and  P"  are  weakly  bisimilar  and 
denoted  with  that  being  the  largest  weak  bisimulation  that  all  weakly  bisimilar  states 
must  enjoy.  In  arriving  at  the  lower  right  via  different  paths,  the  same  visible  actions  are 
encountered  the  same  number  of  times,  albeit  the  order  of  the  actions  may  be  different. 
No  visible  action  is  preempted  from  occurring  its  appointed  number  of  times,  and  the 
strings  r.s/r  and  s.r/s,  though  different,  have  the  same  net  effect.  Strings  such  as  these, 
which  are  equivalent  up  to  pennutation,  are  called  confluence  equivalent. 

Definition  3-3.  Vr.s  e  L*  ,  r  and  5  are  confluence  equivalent  sequences,  written 
r  =conf  s,  if  r/s  =  £  =  s/r. 

In  the  presence  of  confluence,  such  sequences  always  terminate  at  the  same  state  up  to  «. 

A  new  property  called  local  confluence  applies  to  agents  wherein  isolated 
portions  of  their  transition  graphs  can  exhibit  confluence,  even  if  the  root  agent  does  not. 
Milner’s  confluence  is  a  global  property,  insisting  that  all  exiting  sequences  preserve  the 
confluence.  Local  confluence,  by  contrast,  is  content  with  a  portion  of  the  transition 
graph  that  resembles  the  confluence  diagram.  Other  transitions  which  destroy  global 
confluence  are  ignored. 

Definition  3-4.  Let  s  e  L*.  Agent  P  is  locally  confluent  with  respect  to  s  if  P  =>  and 
Vr  =confS,  whenever  P  =>  P'  and  PP>  P"  then  P'  -  P". 

When  local  confluence  occurs,  all  exiting  confluence-equivalent  sequences 
tenninate  at  states  within  the  same  ^-equivalence.  One  often  gives  these  --equivalent 
states  anonymity  and  writes  P=>  «  P'  for  all  such  r.  Note  that  P  can  be  said  to  be  locally 
confluent  with  respect  to  any  of  the  sequences  r.  All  such  sequences  fonn  a  set: 
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Definition  3-5.  Let  P  be  locally  confluent  with  respect  to  s.  The  set  {  r  =COnf  s  :  }  is 

the  confluent  transition  set  ( CT  set )  of  P  with  respect  to  5. 

The  CT  set  does  not  contain  all  permutations  of  s.  It  contains  only  those  of  which 
P  is  capable.  Though  local  confluence  applies  to  both  inputs  and  outputs,  it  is  the  local 
confluence  among  outputs  that  can  be  exploited  by  an  implementation.  CT  sets 
composed  only  of  outputs  are  called  octsets. 

Definition  3-6.  Let  X  be  a  CT  set  of  P  with  respect  to  s.  X  is  an  output  confluent 
transition  set  ( octset )  of  P  with  respect  to  5  if  5  e  jl+. 

For  octsets,  member  sequences  must  be  of  non-zero  length  (5  e  ji+).  This  avoids 
the  burden  of  a  trivial  octset  {^}  which  lends  no  flexibility  in  design  anyway.  In  fact, 
since  only  a  single  member  sequence  needs  to  be  implemented,  the  desire  will  be  to  have 
large  octsets,  composed  of  lengthy  sequences,  for  these  will  give  the  greatest  flexibility 
in  design.  Thus,  the  “lengthiest”  octsets  that  can  be  built  are  called  maxoctsets. 

Definition  3-7.  Let  X  be  an  octset  of  P  with  respect  to  s.  X  is  a  maxoctset  of  P  if 
ate  A  ( P)+  such  that  P  has  an  octset  with  respect  to  st. 

In  the  extreme  case,  when  no  flexibility  in  design  is  offered,  a  maxoctset  is  a  singleton  set 
whose  lone  output  sequence  must  be  implemented.  Every  output  transition 
participates  in  some  maxoctset,  though  it  may  be  as  trivial  as  {a}.  Thus  the  laws 
governing  the  implementation  of  output  can  be  defined  over  the  maxoctsets  of  a 
specification,  and  not  over  the  individual  output  actions  themselves. 
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3.4  Weak  Conformations 

A  family  of  properties  called  weak  conformations  is  now  introduced.  Of  these, 
weak  conformance  will  be  defined  later  as  the  largest  weak  conformation.  Weak 
conformations  are  asymmetric  relations  with  the  specification  agent  on  the  right  and  the 
implementation  on  the  left. 

Definition  3-8.  A  binary  relation  on  processes,  M  c=  <P  x  <P,  is  a  weak  conformation  if 
V  a  e  MS)  u{r},V/?e  ji  (/)  u  {  r),  Vy  e  J4(S) ,  I  M  S  implies  the  following  four  laws: 

Law  of  Specified  Input  or  Tau  (LSIT) 

Whenever  S-^  S'  then  3 1  e  (MS)  u  ‘Extr  (I,S))*  such  that 

(1)  /  A  /' 

(2)  t  \  A(S)  =  & 

(3)  /'  MS' 

Law  of  Specified  Output  (LSO) 

Let  Abe  a  maxoctset  of  S.  3s  e  X and  3t  e  A  (1)+  such  that 

(1)  S±S' 

(2)  i  ±>r 

(3)  t\J(S)  =  s 

(4)  /'  MS' 

Law  of  Implemented  Input  (LII) 

Whenever  /A  /'  and  S (=>  then 

(1)  S*>S’ 

(2)  /'  MS' 
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Law  of  Implemented  Output  or  Tau  (LIOT) 

Whenever  1  A  V  and  8  =  j8\ '  J(S)  then 

(1)  S  i>S’ 

(2)  /'  <WS’ 

LSIT  describes  the  obligation  of  the  implementation  when  the  specification 
requires  an  input  or  z.  The  implementation  answers  by  performing  a  string  t.  Both 
agents  then  evolve  to  derivatives  /'  and  S'  that  also  share  the  relation  eW.  String  t  contains 
one  occurrence  of  an  input  when  a  is  visible  and  none  when  a  -  r.  The  remainder  of  t 
contains  extraneous  outputs  that  can  occur  without  harm  because  they  are  unknown  to  the 
specification.  In  the  statement  of  LSIT,  these  extraneous  outputs  are  filtered  by  the 
projection  onto  A(S).  Other  than  a  lone  a,  t  can  contain  no  other  inputs.  Even  those 

inputs  in  cEytr{I,S)  are  prohibited.  If  t  did  contain  such  unspecified  input  actions,  the 
implementation  would  wait  forever  on  those  inputs,  and  would  thus  be  blocked. 

LSO  describes  how  an  implementation  answers  specified  output  activity.  At 
least  one  sequence  5,  though  possibly  more,  from  each  maxoctset  must  be  “matched”  by 
the  implementation.  The  implementation  matches  s  with  t.  String  t  contains  all  the 
actions  of  s,  in  the  same  sequence  that  they  appear  in  s.  As  before,  t  can  further 
incorporate  any  number  of  extraneous  outputs  without  hann.  One  will  often  say  that  t 
implements  s,  or  alternately,  that  t  implements  X,  since  s  is  the  representative  of  the  entire 
maxoctset  X. 

LII  is  a  reuse  of  Definition  2-6  (2).  It  addresses  the  care  that  must  be  taken  when 
the  implementation  perfonns  an  input  action  within  the  specification  sort.  If  the 
specification  is  not  immediately  capable  of  such  action,  there  is  no  harm  done  because 
that  action  will  not  be  forthcoming  anyway.  If  the  specification  is  immediately  capable 
(SA  )  then  of  course  the  implementation  must  match  that  action  in  accordance  with 
LSIT.  However,  LII  goes  beyond  that  to  state  that  /  is  prohibited  from  any  other  use  of 
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specified  input  symbols,  except  those  arising  by  LSIT.  Otherwise,  the  implementation 
could  stray  into  illegal  behavior  triggered  by  a  legal  input. 

LIOT  addresses  the  occurrence  of  taus  and  specified  outputs  in  the 
implementation.  Although  the  implementation  can  freely  engage  in  extraneous  outputs, 
LIOT  requires  that  any  use  of  specified  output  symbols  in  the  implementation  be  limited 
to  those  that  arise  by  legal  application  of  LSO.  This  prevents  the  implementation  from 
issuing  illegal  behavior  at  pins  that  are  observed  by  the  containing  system. 

Weak  conformations  are  “weak”  because,  like  weak  bisimulations,  they  abstract 
away  z  actions.  For  completeness,  a  definition  of  strong  conformation  appears  in 
Appendix  A,  but  no  attempt  is  made  to  develop  strong  conformation  theory  or  to  pursue 
it  toward  a  congruent  strong  conformance  relation.  As  always,  it  is  the  weak  case  that  is 
more  interesting  and  useful,  and  merits  further  development. 

For  convenience  in  executing  proofs,  corollary  laws  to  the  weak  conformation 
definition  can  be  derived: 

Corollary  3-1.  Whenever  I  VP’S  for  weak  confonnation  W,  the  following  laws  hold: 

Law  of  Input  Coverage  (LIC).  JL(S)  c:  JL(I) 

Law  of  Output  Coverage  (LOC).  A(S)  ci  Jiff) 

Law  of  Specified  Epsilon  (LSE).  Whenever  S=>S'  then  3 1  e  ‘Ex.tr  (I,S)*  such  that 

(1)  I^F 

(2)  /'  WS' 

Law  of  Specified  Abstracted  Input  (LSAI). 

Vae  f(S):  whenever  S=>S'  then  3t  e  (A(S)  u  <Extr  (I,S))+  such  that 

(1)  i±>r 

(2)  t  \  JL(S)  =  a 
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(3)  /'  WS’ 


Law  of  Specified  Input  Strings  (LSIS). 

Vs  e  A(S)+:  whenever  S=>  S'  then  3 1  e  (F(S)  u  E^tr  (I,S)f  such  that 

(1)  i±>r 

(2)  t\MS)=  s 

(3)  /'  WS’ 

Law  of  Implemented  Epsilon  (LIE).  Whenever  I  =^>  /' 

(1)  5=^5' 

(2)  /'  TVS' 

Law  of  Implemented  Abstracted  Input  (LIAI).  V/  e  MI)'-  whenever  /=>/'  then 

(1)  S  k >S ' 

(2)  /'  IV  5' 

Law  of  Implemented  Input  Strings  (LIIS).  Vs  e  _^(S)+:  whenever  I^>I'  and  S^then 

(1)  S=^S' 

(2)  /'  -TV  5' 

Law  of  Implemented  Abstracted  Output  (LIAO).  V/?  e  .^(7):  whenever  /=>  /'  and 

5=  (3  T  j?  (5) 

(1)  S' 

(2)  /'  IV  5' 

Law  of  Implemented  Output  Strings  (LIOS).  Vs  e  J?  (7)+:  whenever  /  =>  /'  t/zen 

(1)  S^>  S' 

(2)  /'  TV  5' 
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Proof:  LIC  and  LOC  follow  directly  from  LSIT  and  LSO.  LSE,  LIE,  LSIS,  LIIS  and 
LIAO  yield  to  induction.  LSAI,  LIAI  and  LIAO  are  shown  by  replacing  ‘  =>  ’  with 
‘=>^=>\  □ 


The  next  two  propositions  follow  readily  from  Definition  3-8: 

Proposition  3-2.  The  process  identity  relation  tdp  is  a  weak  conformation. 

Proof:  Substitute  P  for  both  /  and  S,  and  P'  for  both  /'  and  S'.  □ 

Proposition  3-3.  The  union  of  weak  conformations  is  a  weak  conformation. 

Proof:  V  u  Tfisatisfies  each  law  on  the  strength  of  Vor  VT acting  alone.  □ 

Milner  developed  observational  equivalence  ~  as  the  largest  of  the  weak 
bisimulations,  and  then  strengthened  it  to  a  congruence  by  requiring  initially  stable 
agents  (Milner,  1989:112).  Since  weak  confonnations  are  based  on  bisimulation 
semantics,  this  dissertation  seeks  to  do  the  same,  i.e.,  to  identify  the  largest  weak 
confonnation  and  then  strengthen  it  to  a  congruence  over  CCS.  The  necessary  proofs 
that  follow  make  frequent  use  of  the  composition  °  of  weak  conformations,  relying  on 
such  compositions  to  also  be  weak  conformations.  Hence,  the  demonstration  that  ° 
preserves  weak  conformation  is  essential.  This  requires  that  the  preservation  of  each 
weak  conformation  law  must  be  shown  in  turn. 

To  show  the  preservation  of  LSO,  a  critical  result  concerns  the  string  t  that 
implements  a  specified  maxoctset.  String  t  must  in  turn  define  a  maxoctset  in  the 
implementation.  Assurance  is  needed  that  t  is  neither  lost  within  some  maxoctset  that 


3  °  will  be  called  relational  composition  to  distinguish  it  from  the  Parallel  Composition  of  CCS  processes. 
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exceeds  it,  nor  that  t  outspans  maxoctsets  in  the  implementation  due  to  a  premature 
interruption  of  confluence.  Lemma  3-4  assures  the  former,  and  3-5  the  latter. 

Lemma  3-4.  Let  I'W  S  for  some  weak  conformation  W,  and  let  X  be  a  maxoctset  of  S. 
Let  t  be  an  implementation,  by  I,  of  s  e  X.  There  is  no  maxoctset  Y  of  I  with  respect  to 
some  t.t'  unless  t'l  p  (S)  =  s. 

Proof:  By  contradiction. 

•  Trial  Hypothesis.  Assume  t'l  p  (S)  =  s'  P  s. 

•  By  LSO,  3T,  S'  such  that 

S±S',  /=>/',  tl  p(S)  =  s,  I' TVS'. 

•  Since  t.t'  e  Y,  then  =^>«/". 

•  Vy  e  Y,  lf> «/"  and  y  =conf  t.y '  by  the  definition  of  “octset.” 

•  Since  /'  WS'  then  LIO  demands  that 

S’^>S",  T'VdS". 

•  However,  Vx  e  X,  S=fS'=>S". 

•  .'.  {x.s' :  x  e  X}  is  an  octset  of  S,  and X cannot  be  a  maxoctset. 


Lemma  3-5.  Under  the  same  assumptions  as  Lemma  3-4,  there  is  no  maxoctset  Y  of  I 
with  respect  to  some  proper  prefix  t'  of  t  ( that  is,  t  =  t'.t"  with  t'l  p(S)  =  s'  P  s)  unless 

t"U(S)  =  e. 


Proof:  By  contradiction. 

•  Trial  Hypothesis.  Assume  t"l  p  (S)  =  s"  A  s. 

•  By  LSO,  3/',  I",  S',  S"  such  that 


S±>S'±>S",  t'.t" l  p(S)  =  s'.s"  =  s,  I"WS". 
•  Vv  e  Y,  /=^> «/'  with  y  =conf  t'  by  the  definition  of  “octset.” 
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Since /'=>/"  then  Vy,  /=^>«/'=b>/". 

{y.t"  :y  e  Y]  is  an  octset,  and  Y cannot  be  a  maxoctset. 


Proposition  3-6.  For  weak  conformations,  an  implementing  string  for  a  maxoctset  of 

the  specification  defines  a  maxoctset  in  the  implementation. 

Proof:  Lemmas  3-4  and  3-5.  □ 

Proposition  3-7.  Relational  composition  preserves  LSO. 

Proof: 

•  Let  P  VQ  VdR  and  let  Xbe  a  maxoctset  of  R. 

•  By  LSO  e  J such  that  R^>  R'  and  Qb>  Q'  VdR'  for  appropriate  t. 

•  By  Proposition  3-6,  Q  has  a  maxoctset  V  with  respect  to  t.  P  must  implement  Y, 
though  it  may  indeed  not  implement  t  itself  but  some  other  y  =COnf  t. 

•  Thus  Pib>  P"  V Q"  where  y  =  u  \  y  (Q)  and  Q”  ~  Q'.  Hence  P=>P"  »WR'. 
This  is  almost,  but  not  quite,  the  desired  derivative  relationship. 

•  However,  with  respect  to  Q  R,  y  is  an  implemented  output  string,  so  LIOS 
applies  and  R  R"  where  v  \  a(R)=x  and  Q"  %VR". 

•  Since  v  =Conf  t  then  its  projection  is  x  =conf  5.  Hence,  x  e  Xand  PP>  P"  WPR".  P 
has  implemented  some  x  e  I,  as  desired. 

□ 
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Proposition  3-8.  Relational  composition  preserves  LIOT. 


Proof:  For  P  VQ  <WR  let  PAP’  where  (5  e  JL(P)kj  { r}. 

•  If  /?=  r  then  PAP’  and  by  LIOT,  Q=>Q'  withi3'  VQ\  Applying  LIE  to  Q^Q' 
yields  R^R '  with  Q'  WR'.  Hence  P '  PWR 

•  If  /?  e  A  ( P )  then  applying  LIOT  to  P  V  Q  yields 

Q^Q’,8=p\J{Q),  P’VQ’. 

•  There  are  two  cases  for  S:  (1 )  8=  s  and  (2)  S=  J3. 

•  Case  1.  Apply  LIE  to  Q  TFi?  yielding  R=>  R\  Q'  TF  R'  and  hence  P'  ‘VW Rf. 

•  Case  2.  Apply  LIAO  to  Q  ‘WR  yielding  R  R'  where  S'  =  A  (R),  Q'  iPR' 
and  hence  P'  PWR'. 

□ 


Proposition  3-9.  Relational  composition  preserves  LSIT. 

Proof:  See  Appendix  B. 

The  logical  next  step  is  to  prove  that  the  remaining  law,  LII,  is  preserved  by 
relational  composition.  Unfortunately,  the  preservation  of  LII  cannot  be  proven  under 
the  present  assumptions,  and  the  reason  harks  back  to  the  instability  issue  faced  by  «. 
The  observational  congruence  property  =  solved  this  nicely  by  identifying  the  role  of 
unguarded  r  actions  and  requiring  such  actions  to  be  matched  in  the  initial  agents. 
Milner  then  showed  that  when  P  «  Q  and  both  were  stable,  then  P  =  Q  follows  (Milner, 
1989:Proposition  7.10). 

Within  the  context  of  weak  conformations,  however,  the  issue  of  instability  is 
more  complex.  The  preservation  of  LII  across  P  V  Q  TF  R  fails  because  there  is  no 

7 

obligation  for  the  middle  agent  Q  to  perfonn  an  immediate  =>.  LSO  permits  Q  to 
perform  extraneous  outputs  first.  From  the  standpoint  of  the  specification  R ,  such  outputs 
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are  just  as  spontaneous  and  uncontrollable  as  r  actions.  Thus,  an  output  x  that  is 
extraneous  to  both  A  and  B  creates  an  instability  in  x.A  +B .  The  spontaneous 

occurrence  of  x  can  preempt  the  Choice  of  B.  Hence  no  weak  conformation  exists 
between  x.A  +B  and  A+B.  An  otherwise  stable  implementation  can  be  relatively 

unstable  with  respect  to  the  specification  when  an  extraneous  output  plays  the  role  of  z. 
The  relative  tau  symbol  Zs  will  denote  such  actions  where  the  subscript  S  is  the 
specification  agent’s  name.  Thus  zs  will  admit  both  literal  z  actions  as  well  as  output 
actions  beyond  the  semantic  sort  of  S.4  Relative  stability  is  now  defined. 

Definition  3-9.  P  is  relatively  stable  with  respect  to  Q  if  P  has  no  Zq  derivatives. 

Now,  to  prove  that  LII  is  preserved  by  relational  composition,  it  will  be  necessary 
to  allow  only  initially  stable  agents  with  initial  implementations  relatively  stable. 

Definition  3-10.  The  agent  pair  (/,  S)  meets  the  conformational  stability  (CS) 
assumption  if  S  is  stable  and  /  is  relatively  stable  with  respect  to  S. 

Lemma  3-10.  Relational  composition  preserves  LII  for  weak  conformations  under  the 
CS  assumption. 

Proof:  Write  P  V  Q  W  R  for  weak  conformations  V  and  ‘W.  One  must  establish 
V;/  e  J4(R)  that  whenever  P'  and  f?=>  then  /?=>/?' with  P'  CWR'. 

Y 

•  Since  Q  is  relatively  stable  with  respect  to  R,  LSAI  requires  that  £>=> 
immediately. 

•  :.Q  ^  Q'  with  P'  VQ'  by  LII. 

•  In  turn,  R  R'  with  Q'  ‘WR’by  LIAI. 

4  The  potential  ambiguity  with  z;  (the  synchronization  of.?  and  s)  is  avoided  since  the  relative  r subscript 
is  an  agent  name  (capital  letter)  instead  of  an  action  label  (lower  case  letter). 
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•  Hence  P'  VWR'. 


□ 

Proposition  3-11.  Relational  composition  preserves  weak  conformation  under  the  CS 
assumption. 

Proof:  Propositions  3-7,  3-8,  3-9  and  3-10.  □ 

3.5  Summary 

This  chapter  presented  the  weak  conformations  as  a  set  of  properties  derived  from 
intuitive  notions  of  compliance.  Proposition  3-11  demonstrated  that  relational 
composition  °  preserves  weak  confonnation,  but  not  without  cost.  The  CS  assumption — 
more  general  than  Milner’s  initial  stability  condition — had  to  be  invoked. 

Definition  3-8  is  coinductive,  referring  recursively  to  /'  “WS’  in  each  law,  with  no 
primordial  pair  offered  as  a  basis.  As  such,  many  relations  qualify  as  weak 
confonnations,  including  the  empty  relation.  The  largest,  weak  conformance,  is 
introduced  in  next  chapter. 
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IV.  Weak  Conformance  and  Congruent  Weak  Conformance 


This  chapter  presents  the  largest  of  the  weak  conformations,  called  weak  conformance,  or 
>>,  and  develops  fonnal  results  for  weak  conformance.  Progress  is  begun  toward 
showing  weak  confonnation  to  be  a  congruence,  but  the  attempt  stalls  pending  further 
restrictions  to  CCS  models.  Weak  conformance  is  thus  refined  to  congruent  weak 
conformance  >-w  by  placing  reasonable  design  restrictions  on  CCS  models.  Far  from 
being  severe,  these  restrictions  are  shown  to  be  quite  consistent  with  good  design  intent, 
prohibiting  dubious  practices.  Congruent  weak  confonnance  is  then  proven  to  be  both  a 
partial  order  and  a  congruence.  Partial  orders  that  are  congruent  are  commonly  called 
precongruences.  As  a  precongruence,  >-w  serves  as  a  correct  model  of  safe  substitution. 

4. 1  Weak  Conformance 

Just  as  ~  is  the  largest  weak  bisimulation,  weak  conformance  is  the  largest  weak 
conformation. 

Definition  4-1.  Weak  conformance  >w  =  u  {  !W :  W  is  a  weak  conformation} . 

Proposition  4-1.  >w  is  a  weak  conformation. 

Proof:  Union  preserves  weak  conformation.  □ 

Proposition  4-2.  >-w  is  the  largest  weak  conformation. 

Proof:  Any  weak  conformation  W  c:  >-w  as  a  result  of  Definition  4-1 .  □ 

Proposition  4-3.  >>  is  reflexive. 

Proof:  As  a  weak  conformation,  If  c:  and  hence  P  yw  P  for  all  P.  □ 
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Proposition  4-4.  Under  the  CS  assumption,  >-w  is  partial  order. 1 

Proof: 

•  Reflexivity.  Proposition  4-3. 

•  Transitivity.  Given  P  Q  R,  P  ywR  follows  immediately  since  the  relational 
composition  >>>>  is  a  weak  conformation  and  >-w>-w  c=  >-w. 

•  Antisymmetry.  Given  P  yw  Q  and  Q  >-w  P,  observe  that  both  P  and  Q  are  stable 
under  the  CS  condition,  and  that  no  extraneous  actions  are  possible. 

For  inputs  and  r,  if  P-^P'  then  Q  =>  Q'  P  by  LSIT. 

For  outputs,  if  P  P'  then  Q  TfQ'ywP  by  LIOT. 

Hence  Q  simulates  P. 

Similarly,  P  simulates  Q  and  a  weak  bisimulation  exists  between  the  two. 
Thus  P  «  Q  and,  since  both  are  stable,  P=Q. 

□ 


The  unmodified  weak  conformance  is  not  a  partial  order — the  CS  condition  must 
be  invoked.  Nor  is  the  unmodified  weak  confonnance  a  congruence.  However, 
appropriate  restrictions  to  CCS  models  will  repair  this  deficiency,  such  that  congruence 
can  be  established.  The  refined  property  will  be  called  congruent  weak  conformance. 


The  CS  assumption  must  be  invoked  for  any  proposition  that  relies  on,  or  inherits  a  reliance  on, 
the  relational  composition  of  weak  conformations. 
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4.2  Weak  Conformation  up  to  Weak  Conformance 

A  special  type  of  relation  called  weak  conformation  up  to  weak  conformance  will 
prove  to  be  a  useful  proof  tool.  The  intuition  behind  this  concept  involves  the  use  of  >> 
to  populate  a  sparse  process  relation. 

For  example,  suppose  a  relation  X  contains  only  a  single  pair  (P,  Q ).  If  one 
believes  that  X  expresses  some  sort  of  compliance  relationship,  and  there  are  other 
processes  R  >-w  P,  then  one  may  suppose  that  these  processes  also  share  that  same 
compliance  notion  with  Q.  One  might  wish  to  add  the  pairs  (R,  Q )  to  X.  In  fact, 
(R,  Q )  e  ywX  Furthermore,  since  P  yw  P,  ( P ,  Q)  e  wwX as  well.  Hence  ywX  has  the 
effect  of  adding  pairs  to  X  where  any  R  P  replaces  P.  Though  R  is  not  itself  X- 
compliant  to  Q,  one  can  say  R  is  X-compliant  “within  a  >-w,”  or  “up  to  >-w.”  Similarly, 
one  can  continue  to  augment  the  relationship  with  pairs  created  by  replacing  Q  with  any 
S  such  that  Q  >-w  S.  The  resulting  relation,  ywX  >-w,  in  effect  “builds  up”  X  by  the 
transitive  closure  of  >-w.  If  >-wXw  forms  a  weak  conformation,  then  X  is  the  seed  of  that 
weak  conformation,  and  Xis  called  a  weak  conformation  up  to  >-w. 

Weak  conformations  up  to  >-w  are  useful  because  they  are  contained  within  >-w, 
and  this  fact  makes  an  important  proof  tool.  Occasionally,  it  is  easier  to  show  that  two 
processes  share  a  weak  confonnation  up  to  >-w  instead  of  >-w  directly.  Nevertheless  Xv 
follows  immediately. 

Definition  4-2.  Relation  !W  i s  a  weak  conformation  up  to  weak  conformance  if 
Vae  JL(S)  u{r},V/?G  X(f)^{r},Vye  JL  ( S ),  /  TF  S  implies  the  following  four  laws: 

LSIT'.  Whenever  S S'  then  3 1  e  (A(S)  u  ‘Extr  ( I,S ))*  such  that 

(1)  /  =>  /’ 

(2)  t  r  A(S)  =  & 

(3)  I'XyWxX' 
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LSO'.  Whenever  X  is  a  maxoctset  of  S,  3s  el  and  3t  e  J?  (/)+  such  that 

(1)  S^>S’ 

(2)  /  =»/' 

(3)  tr  J(S)  =  s 

(4) 

LI  I  *.  Whenever  /'then 

(1)  5  ^>5' 

(2)  I'ywWhwS' 

LIOT'.  Whenever  /  -4/'  and  8  =  f\  A(S)  then 

(1) 

(2)  /VwftVwy 

These  “up  to”  laws  differ  from  the  weak  confonnation  laws  only  in  the 
relationship  of  the  derivative  states — that  relationship  being  ‘>-wMS  yf  instead  of  ‘  ‘W  ’ . 
The  “primed”  designation  highlights  this  similarity,  which  is  exploited  to  quickly  execute 
proofs. 

Proposition  4-5.  All  weak  conformations  are  weak  conformations  up  to  >-w. 

Proof:  Each  “unprimed”  law  N  e  {LSIT,  LSO,  III,  LIOT }  has  a  conclusion  /'  MS  S'. 
Rewrite  it  as  /'  I  dp  MS  Idp  S'.  Since  I  dp  c=  >>  one  derives  /'  >-wTtWw  5"  thus  establishing 
the  corresponding  law  N'.  □ 

Proposition  4-6.  If  MS  is  a  weak  conformation  up  to  then  ywMfw  is  a  weak 
conformation  under  the  CS  assumption. 
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Proof:  Show  that  I  ywUfw  S  satisfies  the  weak  conformation  laws.  For  each 

“unprimed”  law  N  e  {LSIT,  LSO,  LII,  LIOT } : 

•  Write  Iyw  P  WQ  S. 

•  Apply  Law  N  to  each  and  Law  N'  to  rW. 

•  The  resulting  derivative  relationships  are:  /'  >-w  P',  P'  twWfiw  Q',  and  Q'  >-w  S'. 

•  By  composition  /'  ^w^wTtAw  >-w  S',  which  reduces  to  /'  >wW>lw  S'. 

•  Hence  >-w‘MAw  satisfies  Law  N. 

□ 


Proposition  4-7.  If‘Wis  a  weak  conformation  up  to  >-w  then  ‘W  c  >-w  under  the  CS 
assumption. 

Proof:  W  =  If  Wlf  c  □ 

Proposition  4-7  is  the  result  that  will  serve  as  a  useful  proof  tool.  To  show  that 
I  ywS  it  suffices  to  show  that  a  weak  conformation  up  to  >-w  exists  between  /  and  S. 

Proposition  4-8.  All  bisimulations  ( including  «  and  ~)  are  weak  conformations  ( and  by 
Proposition  4-5,  they  are  weak  conformations  up  to  >-w  a /.so). 

Proof:  There  are  no  extraneous  actions  between  bisimilar  processes;  and  the  back  and 
forth  laws  of  bisimulation  are  stricter  than  the  weak  confonnation  laws.  Thus  the  proof 
of  each  weak  conformation  law  is  straightforward.  □ 

4.3  Congruent  Weak  Conformance 

Milner  found  that  «  is  not  a  congruence  over  the  unmodified  CCS,  so  he 
constructed  the  slightly  finer  =  to  serve  as  a  congruence.  Similarly,  >-w  is  not  a 
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congruence  over  CCS,  and  a  slightly  finer  confonnation  is  needed.  Thus  a  congruent 
weak  confonnance  (to  be  symbolized  as  ‘hw’)  is  desired. 

One  restriction  has  already  been  imposed — the  CS  assumption — to  assure  the 
relational  composition  of  weak  conformations.  The  CS  assumption  disposes  of  initial 
instability,  a  difficulty  faced  by  *  as  well. 

An  additional  difficulty  stems  from  the  possibility  of  extraneous  actions  being 
“promoted”  to  specified  actions  during  the  construction  of  compound  agents.  This  is  not 
an  issue  for  equivalences,  where  there  are  no  extraneous  actions.  To  achieve  a  congruent 
weak  confonnance  over  CCS  constructions,  one  must  prevent  extraneous  actions  from 
being  promoted  during  the  course  of  the  construction.  Extraneous  actions  prior  to  the 
construction  must  remain  extraneous  after  the  construction,  unless  they  disappear  entirely 
from  the  sort  of  the  composite  implementation.  Suppose  one  has  S  =  b.NIL  and 

def  — 

I  =  b.c.NIL  +  d.NIL.  A  weak  conformation  exists  between  specification  S  and 
implementation  I.  The  CS  assumption  holds,  and  c  and  d  are  allowable  extraneous 
actions.  Clearly,  however,  c.I  does  not  conform  to  c.S  nor  does  d.I  conform  to  d.S.  The 
Prefix  operation  has  “promoted”  extraneous  actions  c  and  J[rwbi]. 

Ah  the  CCS  constructors  (except  Restriction)  can  create  problems  by  unwittingly 
promoting  extraneous  actions  to  specified  actions.  Therefore,  to  obtain  a  congruent  weak 
confonnance  relation,  CCS  constructions  need  to  be  constrained  to  disallow  such 
promotion.  This  prohibition  is  not  an  unworkable  limitations.  Rather,  it  is  consistent 
with  good  design  sense.  Indeed,  the  behavior  of  an  extraneous  pin  is,  by  its  very  nature, 
a  “don’t  care”  issue.  To  suddenly  levy  requirements  on  the  “don’t  care”  pin  at  a  higher 
level  of  abstraction  represents  a  questionable  change  in  designer  intent. 

Definition  4-3.  Let  (/,  S  )  be  an  indexed  system  of  agents  such  that  /,  Si  for  weak 
conformation  Tfi .  Let  E{X)  be  a  CCS  expression  on  multiple  agents  denoted  by  indexed 
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variable  X.  E{X }  can  employ  all  constructors  except  Restriction  and  Relabeling.  E{X) 
meets  the  Preservation  of  Extraneous  Action  (PEA)  condition  if: 

(1)  ExtiiJi,  Si)  c=  cExtr(E{I},E{S})  for  all  indices  i. 

(2)  ‘Extr  (/„  Si)  c=  ‘ExP’  (E{I},E{S})  for  all  i. 

PEA  guarantees  that  all  extraneous  actions  remain  extraneous  after  the  construction 
E{X}  so  that  unreachable  paths  are  not  inadvertently  activated. 

In  addition  to  PEA,  one  needs  assurance  that  no  coactions  are  introduced  that  can 
synchronize  with  extraneous  actions.  Such  synchronization  can  activate  unreachable 
paths  via  the  silent  action  r.  This  necessitates  yet  another  design  constraint: 

Definition  4-4.  Under  the  same  assumptions  as  Definition  4-3,  if,  for  all  Parallel 
Compositions  (Ej  {X}\E2{X})  within  E\X\ : 

(1)  Vae  JHEi{S)),at  Extr  (E2{7  },E2{S  }) 

(2)  Va  eI(E,{S}),a  £  <E ytr(E2{I  }£2{S  }) 

(3)  Va  e  A(E2{S}),a^Extr(E1{T},E1{S}) 

(4)  VaeJ(E2{S}),a£  <Extr(E,{I  },Ej{S  }) 

then  E{X  \  meets  the  Extraneous  Synchronization  Prohibition  (ESP)  with  respect  to 
(T,S). 


Given  the  design  constraints  (CS,  PEA  and  ESP)  introduced  thus  far,  one  now 
proceeds  to  prove  that  each  combinator  preserves  >-w,  given  the  constraints.  The 
propositions  are  stated  as  generally  as  possible,  invoking  only  the  necessary  condition(s), 
and  applying  to  general  weak  confonnations  when  possible,  and  to  >-w  alone  only  when 
necessary. 


4-7 


Proposition  4-9.  A  weak  conformation  ‘W  is  preserved  by  the  Prefix  combinator  under 
the  PEA  restriction. 

Proof:  Given  I  Vd  S,  show  that  Va  e  Act  :  a.I  W  a.S.  Observe  that  a  is  the  only 
immediate  action  that  a.I  and  a.S  can  perform,  and  PEA  assures  that 
a  £  {fExtr  (I,S)  u  ‘Expfid.S)).  Thus  a  lies  within  both  L{I)  and  L(S),  or  neither. 

•  LSIT.  a  e  yl(S)u{r}.  a.S-^AS,  a./=>7  using  t=  a.  The  target  states  are  /  AYS. 

•  LII  and  LIOT.  Similar. 

•  LSO.  <2  e  A(S).  Let  Abe  a  maxoctset  of  S. 

Y  =  {a.s  :  s  e  X}  is  a  maxoctset  of  a.S. 

By  LSO,  3 r  e  ji  (I  f  such  that  r  implements  some  x  e  X where 
/A  S^>  S',  r\  J(S)  =  x,  /'  <WS’. 

Now  a.I  ■%  A  /'  and  a.S^A  S'  with  a.x  e  Y. 

If  a  £  r  then  r  \  A  ( a.S)  =  r\  A  (S)  =  x. 

If  a  e  r  then  by  PEO  a  £  (Eytr  (I,S)  and  .'.a  e  A(S)=  A  ( a.S ).  Again, 
r  X  A  (S)  =  x. 

Since  r  \  A  (S)  =  x  independent  of  whether  a  e  r  then  a.r  1  A  ( a.S)  =  a.x. 
Now  a.x  e  Y  and  a.r  is  an  implementation  of  a.x  e  Y . 

□ 

To  show  that  Summation  or  Choice  preserves  a  weak  confonnation,  one  must 
know  how  the  maxoctsets  of  the  Summation  are  fonned  from  the  maxoctsets  of  the 
components.  Hence  the  next  lemma: 

Lemma  4-10.  Let  M  be  a  maxoctset  of  R  =  S  +  T.  Let  M  =  Ms  u  Mj  where 
Ms  =  {.s'  e  M  :  SX  }  and  Mt=  {.s'  e  M :  TX  }.  Ms  and  Mr  are  maxoctsets  of  S  and  T, 
respectively. 
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Proof:  By  contradiction. 

•  Vx,  y  e  M  \  RM~  R',  RM~  R'  and  x  =COnf  y  since  M is  a  maxoctset. 

•  Vx,  y  e  /V/v  \  R=>~  R',  R=>~  R'  and  x  =COnf  y  since  Ms  c:  M. 

•  S ince  x,  y  belong  to  S,  SM»R',  SM»R' 

•  Thus  Ms  is  at  least  an  octset  of  S.  Similarly,  MT  is  an  octset  of  T. 

•  Trial  Hypothesis.  Assume  one  is  not  a  maxoctset.  W.l.o.g.  let  it  be  Ms. 

•  Then  S  must  have  some  maxoctset  Ms'  with  respect  to  some  s.s '  where  sM  s. 

•  Vx'  e  Ms  :  let  x '  =  y.z,  where y  e  Ms  and  z  =conf  5 

•  Let  SMS'M  S”. 

•  VxeMA+f^-ii'. 

•  Since y  e  M,  one  must  have  R'  ~  S'. 

•  Since  S'  M  S"  then  R'  MR" ~S". 

•  R  =  S  +  T has  an  octset  with  respect  to  x.z  and  M  cannot  be  a  maxoctset  of  R. 


Proposition  4-11.  A  weak  conformation  M>  is  preserved  by  Summation  under  the  PEA 
assumption. 

Proof:  Given  I  M’S  and  J  M’T,  show  that  I  +  J  Vd  S  +  T,  assuming  w.l.o.g.  that  any 
transition  out  of  S  +  T  has  S  as  its  source. 

•  LSIT.  S  +  T  S'  for  a  e  J?  u  {  r} . 

By  LSIT,  IMP  M’S'.  Yet  if  /  A  /'  then  I  +  JM  /'. 

To  show  that  t  \  A(S  +  T)=  a  ,  assume  otherwise: 

3  a  e  t  such  that  a  &  A  (J)  while  a  £  MS). 

This  violates  PEA. 


4-9 


LII  and  LIOT.  Similar. 


• 

•  LSO.  Apply  Lemma  4-10.  Any  maxoctset  of  S  +  T  is  of  the  form  M  =  M$  u  MT. 
Ms  and  MT  are  maxoctsets  of  S  and  T,  respectively. 

Ms  and  MT  each  must  contain  at  least  one  implemented  string. 

.‘.Mmust  contain  at  least  two  implemented  strings. 

If  s  e  Ms  is  implemented  by  /,  then  I  HI’  -‘W S'. 

.-./  +  J  =>  /'  for  S'  +  T  H  S'  thus  I  +  J  implements  s. 

The  argument  for  s  e  Mr  is  similar. 

□ 

To  show  that  Parallel  Composition  preserves  weak  conformation,  one  must  know 
how  maxoctsets  of  a  Parallel  Composition  are  formed  from  the  maxoctsets  of  the 
components.  Hence  Lemma  4-12  is  given  to  aid  Proposition  4-13. 

Lemma  4-12.  Let  Y\...Yn  be  all  the  maxoctsets  of  S  and  let  Zi...Zm  be  the  all  the 
maxoctsets  ofT.  Let  si...sn  be  defining  sequences  for  Yi...Yn,  respectively.  Similarly,  let 
ti...tm  be  defining  sequences  for  Z]  ...Zm.  The  maxoctsets  of  (S  \  T)  are  precisely  the  nm 
octsets  with  respect  to  st.  th  for  1  <  i  <  n  and  1  <  /  <  m. 

Proof:  See  Appendix  B. 

Proposition  4-13.  A  weak  conformation  TP  is  preserved  by  Parallel  Composition  under 
the  PEA  and  ESP  conditions. 

Proof:  See  Appendix  B. 

Next,  consider  Restriction  and,  in  particular,  Restriction  of  inputs.  One  can  safely 
Restrict  specified  inputs,  since  their  removal  does  not  affect  the  ability  of  the 
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implementation  to  obey  LSIT  and  LII  with  respect  to  the  remaining  inputs.  Extraneous 
inputs  can  also  be  safely  Restricted.  Naturally,  one  can  also  Restrict  any  input  symbols 
external  to  both  the  specification  and  implementation,  since  such  Restriction  does  not 
modify  the  base  agents  at  all.  In  conclusion:  there  is  no  limitation  on  Restricting  inputs. 

Now  consider  the  Restriction  of  outputs.  First  note  that  specified  outputs  can  be 
safely  Restricted.  In  the  case  of  the  LSO  law,  Restricting  a  single  specified  output  action 
will  remove  from  consideration  every  maxoctset  in  which  it  participates,  since  that  action 
must  appear  in  every  string  of  that  maxoctset.  The  Restriction  of  outputs  external  to  both 
sorts  is  moot,  as  was  the  case  for  inputs.  However,  one  must  take  care  when  Restricting 
extraneous  outputs,  for  they  can  appear  within  implementing  strings,  and  their 
Restriction  will  block  these  strings.  The  only  extraneous  output  actions  that  can  be  safely 
be  Restricted  are  those  whose  only  occurrences  lie  along  unreachable  paths.  This  special 
type  of  extraneous  output  is  called  an  idle  output  action: 

Definition  4-5.  a  e  ‘Eytr(I,S)  is  an  idle  output  action  of  /  !WS  if  for  every  derivative  /' 
of  /,  whenever  /'  3  S'  a  derivative  of  S  such  that  /'  ‘W  S'. 


Definition  4-6.  IcCCe  (/  WS)  =  {  a  :  a  is  an  idle  output  action  of  I  VdS.  } . 

One  can  now  define  the  conditions  required  to  achieve  congruence  for  weak 
confonnations  under  Restriction. 

Definition  4-7.  The  label  set  L  e  L  meets  the  Congruent  Output  Restriction  (COR) 
condition  with  respect  to  a  weak  conformation  /  Tfi  S  if  Va  e  L,  a, a  <£  Eytr  (I,S)  - 
IcfCe  (I  -WS). 
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The  COR  condition  forbids  the  Restriction  of  extraneous  outputs,  unless  they  are 
idle.  Thus  three  kinds  of  outputs  may  be  safely  restricted:  (1)  specified  outputs,  (2)  idle 
outputs  and  (3)  outputs  external  to  both  j?  (I)  and  J?  (5),  whose  restriction  is  moot. 

Proposition  4-14.  Restriction  preserves  a  weak  conformation  when  the  COR  condition 
is  met. 

Proof:  See  Appendix  B. 

Finally,  consider  Relabeling.  This  operator  can  cause  congruence  failure  if  the 
Relabeling  function  assigns  the  same  name  to  previously  distinct  symbols.  Therefore, 
one  must  require  that  the  Relabeling  function  be  one-to-one,  in  other  words,  an  injection. 
Also,  those  signals  not  explicitly  renamed  are  implicitly  renamed  to  their  “old”  names, 
which  of  course  must  not  collide  with  any  “new”  names,  so  the  function  must  in  fact  be  a 
bijection. 

Definition  4-8.  A  Relabeling  function  meets  the  bijective  relabeling  ( BR )  condition  if  it 
is  a  bijection. 

Proposition  4-15.  Relabeling  preserves  weak  conformation  under  the  BR  condition  . 
Proof:  Similar  to  Proposition  4-14. 

It  remains  to  show  that  congruent  weak  conformance  is  preserved  under  recursive 
definition.  This  cannot  be  shown  for  general  weak  conformations,  or  even  for  >-w.  It  can 
however  be  demonstrated  for  >-w  when  the  CS,  PEA,  ESP,  COR  and  BR  conditions  apply. 

Proposition  4-16.  If  A  =  P  then  A  yw  P . 
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Proof:  A  =  P  implies  A  ~  P  (Milner,  1989:Propostion  12.11).  Since  ~  is  a  weak 
conformation  then  ~  c:  >-w.  A  >-w  P  follows.  □ 

Proposition  4-16  allows  one  to  conduct  the  proof  of  Proposition  4-17  with  respect 
to  a  single  variable.  It  is  understood  that  Proposition  4-17  will  be  easily  extended  to  the 
multivariate  case.  The  proof  of  Proposition  4-17  is  by  transition  induction  (Milner, 
1989:58,  100),  a  form  of  coinduction  (Wegner  and  Goldin,  1999). 

Proposition  4-17.  Let  E  F  where  expressions  E  and  F  contain  at  most  the  single 
variable  X.  Under  the  CS,  PEA,  ESP ,  COR  and  BR  conditions,  whenever  I  =E{I/X}  and 
S  =F{S/X}  then  I  ^S. 

Proof:  See  Appendix  B. 

Though  >-w  itself  is  not  a  congruence,  the  previous  propositions  show  that  >w  is 
preserved  by  each  combinator,  if  the  five  design  restrictions  apply.  Hence,  a  weak 
confonnation  exits,  slightly  finer  than  which  is  a  congruence.  This  desired  relation  is 
called  congruent  weak  conformance  >-w. 

Definition  4-8.  Let  /  >-w  S.  Furthermore  assume  that  the  CS,  PEA,  ESP,  COR  and  BR 
conditions  apply.  Then  /  and  S  enjoy  the  congruent  weak  conformance  relation,  written 
IPwS. 

Proposition  4-18.  >-w  is  a  congruence. 

Proof:  Propositions  4-9,  4-1 1,4-13,  4-14,  4-15,  4-17.  □ 
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Proposition  4-18  is  a  major  result,  establishing  >-w  as  a  correct  model  for  safe 
substitution.  It  now  remains  to  justify  the  earlier  conjecture  that  >-w  is  a  partial  order. 
Now  >w  is  already  known  to  be  a  partial  order  under  the  CS  assumption.  As  a  refinement 
of  weak  conformance  that  includes  CS  among  other  conditions,  it  follows  that  hw  is  a 
partial  order. 

Proposition  4-19.  >-w  is  a  partial  order. 

Proof:  Proposition  4-4.  □ 

4.4  Summary 

In  the  last  chapter  a  set  of  properties  called  weak  conformations  were  established 
under  four  laws  that  embody  intuitive  notions  of  hardware  compliance.  In  this  chapter, 
the  largest  of  the  weak  conformations  was  designated  weak  conformance  and  given  the 
symbol  >>.  To  serve  as  a  model  for  safe  substitution  of  hardware,  >-w  had  to  be  shown  to 
be  a  congruence,  i.e.,  that  it  be  preserved  by  all  CCS  operators.  To  achieve  this  goal,  it 
was  necessary  to  limit  CCS  constructions  by  the  five  conditions:  CS,  PEA,  ESP,  COR 
and  BR.  Happily,  these  conditions  are  consistent  good  design  intent.  Weak 
conformance,  when  refined  by  these  five  conditions,  yields  the  property  of  congruent 
weak  conformance  >-w. 

Congruent  weak  confonnance  >-w  was  developed  and  proven  to  be  a  congruent 
partial  order,  or  precongruence.  This  precongruence  derives  maximal  flexibility  and 
embodies  ah  weaknesses  in  input,  output,  and  no-connect  signals  via  the  four  transitional 
laws  of  weak  confonnation.  Five  construction  restrictions  assure  that  >-w  is  a  fully 
replaceable  model  of  conformance  to  specification.  This  is  the  best  formal  relation 
known  for  verifying  implementations  against  specifications. 
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In  the  next  chapter,  a  hypothetical  VHDL-to-CCS  translator  is  validated  using 
congruent  weak  conformance. 
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V.  VHDL-to-CCS  Translation 


5.1  Introduction 

In  the  previous  chapter,  the  property  of  congruent  weak  conformance  >-w  was 
proven  to  be  a  precongruence,  and  therefore  a  correct  model  of  safe  substitution.  The 
present  chapter  applies  Aw  to  a  practical  problem:  the  translation  of  VHDL  code  to  CCS. 
The  two  languages  have  different  semantics,  so  the  translation  problem  is  challenging. 

VHDL  has  informal  simulation  semantics,  which  are  defined  in  the  VHDL 
Language  Reference  Manual  (IEEE,  1992).  The  semantics  of  CCS  are  given  by  its 
transition  rules  (Milner,  1989:  45,  57).  Fundamental  differences  between  VHDL  and 
CCS  semantics  are:  (1)  simulation  versus  bisimulation  semantics,  (2)  quantitative  versus 
indefinite  time,  (3)  complete  hiding  of  internal  action  versus  abstraction  of  hidden  action 
to  r,  (4)  broadcast  versus  handshake  communication,  (5)  level-signal  versus  transitional 
semantics  and  (6)  simultaneity  versus  interleaving  concurrency. 

5.1.1  Simulation  and  Bisimulation  Semantics.  The  VHDL  simulation  cycle  is  a 
three  part  repeating  sequence  that  (1)  responds  to  current  events,  (2)  posts  future  events 
as  transactions 1  onto  the  drivers  (event  lists)  that  correspond  to  each  signal,  and  then  (3) 
advances  the  simulation  clock  to  the  next  scheduled  transaction  (Lipsett  and  others,  1989: 
12-13).  The  Language  Reference  Manual  defines  the  meaning  of  each  VHDL  construct 
by  how  an  event-based  simulator  interprets  and  executes  it.  Since  the  simulation  cycle  is 
so  central  to  VHDL  semantics,  fonnal  models  of  VHDL  code  often  include  a  formal 
model  of  a  simulation  engine  (Fujita  and  others,  1983;  1983a;  Read  and  Edwards,  1994; 
van  Tassel,  1994). 

CCS,  on  the  other  hand,  supports  bisimulation  semantics  in  which  processes  are 
differentiated  by  the  actions  they  can  potentially  perfonn. 

1  An  event  is  a  signal  transition  that  has  actually  been  accomplished  by  the  simulator.  Transactions,  on  the 
other  hand,  represent  potential  future  events.  The  simulator  removes  transactions  from  the  signal  drivers 
and  creates  events. 
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5.1.2  Time.  For  VHDL,  events  are  separated  in  quantitative  time  by  a  simulation 
clock,  and  the  duration  between  events  can  be  precisely  calculated.  An  infinitesimal 
quantity  of  time  called  delta  is  also  supported  (Bhasker,  1999:  74).  Delta  is  tied  to  the 
simulation  cycle,  and  corresponds  to  the  minimum  advance  of  the  simulation  clock. 
When  a  transaction  is  first  posted  to  a  signal  driver,  and  no  delay  is  specified,  the 
simulation  cycle  must  nevertheless  complete  a  repetition  in  order  to  react  to  it  and 
produce  an  event.  Each  advance  of  one  delta  corresponds  to  one  repetition  of  the 
simulation  cycle  when  the  simulation  clock  itself  does  not  advance.  Thus,  events  can  be 
separated  by  one  or  more  deltas  while  occurring  at  the  same  simulation  time.  Deltas 
enforce  a  strict  ordering  among  otherwise  simultaneous  events  or  transactions.  A 
transaction  scheduled  two  deltas  after  the  present  is  considered  to  be  strictly  later  than 
one  scheduled  one  delta  later.  However,  no  number  of  deltas  can  exceed  the  smallest 
finite  delay  time. 

Although  CCS  can  express  the  ordering  of  actions,  duration  between  actions  is 
indeterminate  since  time  is  not  quantified.  Pending  actions  simply  occur  at  some 
indefinite  future  time. 

5.1.3  Abstraction.  When  hierarchical  models  are  built  in  VHDL,  internal  signals 
between  components  disappear  entirely  from  the  port  list  of  the  composite.  Thenceforth, 
such  internal  actions  can  neither  be  manipulated  nor  observed  by  the  environment. 

For  CCS,  internal  action,  though  hidden,  remains  expressed  at  the  top  level  as  r. 
A  r  cannot  be  manipulated  or  directly  observed,  but  it  does  have  an  effect  on  observed 
behavior  due  to  its  ability  to  preempt  potential  actions. 

5.1.4  Communication.  VHDL  allows  broadcast  communications.  Several  wires 
can  connect  to  a  single  node.  Thus,  multiple  processes  or  components  can  read  the  value 
of  a  single  signal.  That  signal  need  not  be  explicitly  split  to  service  each  process  or 
component  individually.  The  ability  of  a  single  output  signal  to  drive  multiple  processes 
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is  commonly  is  called  fanout.  Similarly,  two  or  more  processes  can  drive  a  single  node 
in  VHDL  if  the  designer  provides  a  resolution  function  (Bhasker,  1999:  1 1 1). 

CCS,  on  the  other  hand,  uses  handshake  communication.  Such  communication  is 
strictly  one-to-one  and  occurs  when  one  agent  offers  and  action  and  another  the 
corresponding  coaction.  If  two  receivers  attempt  to  handshake  on  the  same  action,  one  of 
them  fails  to  communicate.  Thus,  a  lone  signal  cannot  directly  drive  multiple  devices. 
Multiple  fanout  must  be  modeled  indirectly  by  providing  a  FORK  agent  to  explicitly 
provide  multiple  copies  of  an  action  to  communicate  with  all  offered  coactions.  Yet  the 
FORK  still  fails  to  accurately  model  the  broadcast  communication  of  VHDL.  For 
VHDL,  a  single  event  along  a  multiply  connected  node  is  simultaneous  along  all 
branches.  For  the  CCS  FORK,  occurrences  along  each  branch  must  be  ordered,  and  the 
time  separation  between  them  is  undetermined. 

By  requiring  FORKs,  pure  CCS  supports  the  delay-insensitive  hazard  model  of 
asynchronous  design  (Seitz,  1980:  246).  The  many  branches  of  a  wire  node  are  modeled 
as  operating  independently.  VHDL  communication,  on  the  other  hand,  matches  the 
speed-independent  hazard  model,  where  the  delays  along  the  various  branches  of  a  node 
are  presumed  so  close  as  to  be  negligible  (Seitz  1980:  250).  A  single  signal  passes 
through  the  various  branches  at  essentially  the  same  time. 

A  modified  version  of  CCS  adds  operators  to  achieve  the  ability  to  model 
broadcast  communication  (Stevens,  1994:  180-5).  In  particular,  this  version  adds  a 
conjunction  operator  |c  to  model  broadcast  communication  among  parallel  agents.  The 
conjunction  operator  is  similar  to  the  ||  operator  of  CSP  (Hoare,  1985). 

The  delay-insensitive  model  is  very  strict.  The  designs  that  can  be  produced 
under  its  regimen  are  very  few.  Thus,  the  broadcast  version  of  CCS  thus  makes  a  more 
practical  translation  target.  In  this  chapter,  the  consequences  of  translation  to  both 
versions  of  CCS  are  explored. 
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5.1.5  Level  Signals  and  Transitional  Semantics.  VHDL  assigns  explicit  level 
values  to  its  signals  and  does  not  simply  direct  them  to  “change.”  Most  assignment 
statements  are  explicit  in  this,  such  as  “X  <=  1”. 

In  contrast,  CCS  models  transitions  without  specifying  what  the  level  values  are. 
Thus  when  FIFO  =  in. out. FIFO  one  can  sunnise  that  in  and  out  start  at  ‘0’  and  after 

one  iteration  they  transition  to  ‘1’,  back  to  ‘0’  after  two  iterations,  and  so  forth.  An 
equally  valid  interpretation  starts  them  at  opposite  values  ‘0’  and  ‘1’,  and  they  forever 
transition  in  opposite  directions.  In  CCS,  level  values  are  simply  undefined  since  they 
are  irrelevant  to  the  transitional  semantics. 

Now  VHDL  code  can  take  on  the  appearance  of  transitional  instead  of  level- 
signal  semantics.  Assignment  statements  such  as  “X  <=  not  X”  are  quite  legal. 
Nevertheless  the  resulting  transaction  must  be  to  a  level  value.  Thus,  the  present  value  of 
X  must  be  noted,  and  an  assignment  to  the  opposite  value  posted  to  the  driver.  One 
cannot  merely  schedule  X  to  “switch  value.”  Even  though  VHDL  code  can  appear 
transitional,  the  underlying  simulation  semantics  does  not  support  it. 

Interestingly  enough,  a  VHDL  transaction  can  be  ineffective  in  creating  a  real 
transition.  For  example,  if  a  transaction  is  scheduled  to  drive  X  to  ‘1’,  yet,  due  to 
previous  events,  X  is  already  at  ‘  1  ’,  then  no  real  transition  occurs. 

5.1.6  Simultaneity  versus  Concurrency.  VHDL  allows  simultaneous  events,  since 
transactions  can  bear  the  same  time  stamp.  Microscopic  ordering  by  delta  delays  is  not 
even  required.  Transactions  can  indeed  be  scheduled  to  occur  on  the  same  delta  cycle. 

CCS  however,  engages  in  interleaving  concurrency.  CCS  does  not  recognize 
absolute  simultaneity,  taking  the  view  that  a  fine  enough  division  of  time  will  unveil  an 
ordering  among  seemingly  simultaneous  actions.  CCS  actions  can,  however,  be 
considered  concurrent.  Concurrent  actions  are  not  necessarily  simultaneous.  Rather, 
their  relative  order  is  simply  indeterminate.  Therefore,  one  writes  x.y  +  y.x  or,  more 
compactly,  (x\y)  to  indicate  this  uncertainty. 
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5.2  Translation  Rationale 


Due  to  semantic  mismatches  such  as  those  given  in  section  5.1,  translation  from 
one  semantic  system  to  another,  by  its  very  nature,  cannot  preserve  all  meaning.  Some 
information  must  necessarily  be  lost,  whether  it  be  explicit  simulation  time,  the  ability  to 
model  simultaneity,  the  ability  to  discriminate  based  on  bisimulation,  etc. 

If  infonnation  is  lost,  then  why  perform  such  a  translation  at  all?  One  reason  is 
this:  the  designer  may  wish  to  reuse  off-the-shelf  component  models,  and  they  may  not 
all  be  available  in  a  single  language.  Secondly,  the  designer  may  wish  to  exploit  the 
verifications  that  another  system  can  offer.  These  verifications  may  be  more  accurate, 
more  efficient,  or  use  a  stricter  semantics  than  is  possible  in  the  source  language. 

Yet  if  transformed  models  are  not  semantically  equivalent  to  their  originals,  how 
can  post-transformational  verifications  be  deemed  valid?  Such  verifications  are  valid  if 
the  translation  process  preserves  an  appropriate  property.  Since  the  ultimate  goal  of  a 
designer  is  to  “substitute”  his  design  for  a  specification,  then  safe  substitution  (or 
congruence)  is  the  property  that  must  be  preserved  by  the  translation.  As  the  loosest 
known  congruence  modeling  device  compliance,  >-w  is  thus  the  property  that  must  be 
preserved  by  inter-semantic  translation. 

This  chapter  shows  how  >-w  can  be  used  to  validate  such  transformations.  First, 
some  very  basic  agents  are  identified.  The  agents  are  detailed  enough  to  represent  the 
salient  features  of  the  CCS  and  VHDL  semantics,  and  will  be  used  to  illustrate  the 
translation  process.  Both  VHDL  and  CCS  models  will  be  proposed  for  these  agents.  By 
comparing  these  models,  the  characteristics  of  a  VHDL-to-CCS  translator  will  be 
derived.  The  translation  rules  discovered  during  the  course  of  this  exercise  will  then  be 
enumerated.  These  transformations  will  then  be  shown  to  preserve  >-w. 

The  VHDL-to-CCS  translator  discussed  in  this  chapter  is  not  an  implemented 
translator.  The  purpose  of  this  chapter  is  to  infer  the  general  characteristics  of  such  a 
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translator.  This  serves  two  purposes:  (1)  to  demonstrate  the  feasibility  of  such  a 
translator  and  (2)  to  show  that  such  a  translator  with  these  characteristics  preserves  >-w. 

5.3  Translation  Models 

Consider  three  buffer  specifications  F,  G,  and  H.  Each  is  a  one-token  buffer.  F  is 
the  same  as  the  familiar  one -place  FIFO  (Equation  2-3).  G  and  H  are  contrived  examples 
created  to  provide  instances  of  extraneous  input  and  output.  G  is  like  F  except  that  G 
produces  duplicate  outputs  concurrently,  rather  than  a  single  output.  Hence  G  has  a 
maxoctset  {  o.p ,  p.o  } .  H  has  two  input  lines  as  well  as  two  output  lines.  One  input 

requests  F-like  behavior,  i.  e. ,  one  output.  The  other  input  requests  G’ s  behavior,  i.e.,  two 
outputs.  Unlike  G  however,  H  produces  a  specific  interleaving  of  the  dual  outputs,  not 
both  alternatives.  Thus  H  is  an  implementation  of  G  that  takes  a  single  path  through  the 
maxoctset  in  accordance  with  LSO. 

The  models  for  these  buffers  appear  in  this  section  in  three  distinct  groups: 
(1)  reference  models,  (2)  initial  models  and  (3)  target  models. 

The  reference  models  appear  first.  These  models  merely  document  the  behavior 
under  discussion.  For  brevity,  the  reference  models  are  given  in  CCS.  However  they  are 
not  the  subject  of  translation,  since  the  intent  is  to  study  VHDL-to-CCS  translation,  and 
not  the  reverse. 

The  initial  models  then  are  VHDL  models  inspired  by,  but  not  necessarily 
faithful  to,  the  reference  models.  Semantic  differences  will  necessarily  limit  the  fidelity 
of  the  initial  models  to  the  reference  models. 

The  target  models  are  CCS  models  derived  from  the  initial  models  by  the 
application  of  translation  rules.  Again,  semantic  differences  will  limit  the  fidelity  of  the 
target  models  to  the  initial  models.  However,  whereas  the  initial  models  derive  from  the 
reference  models  by  inspiration,  the  target  models  derive  from  the  initial  models  by  a 
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disciplined  approach.  One  should  not  expect  the  translation  process  to  recover  the 
reference  models. 

Here  are  the  basic  reference  models  for  agents  F,  G  and  H: 


def 

F  =  i.o.F 

(5-1) 

G  =  i.(o\p).G 

(5-2) 

FI  =  i.o.p.H+  j.o.H 

(5-3) 

One  can  also  make  two-token  buffers  using  the  same  protocol.  Here  are  two- 
token  reference  models  FF  and  GG  that  are  analogous  to  F  and  G  respectively: 


def 

FF  =  i.FFl 

FF1  =  d.FF+i.o.FFl  (5-4) 

GG  =  i.GGl 

GGl  =  j.{o  |  p).GG  +  i.(o  |  p).GG\  (5-5) 

A  two-token  buffer  HH  corresponding  to  H  could  also  be  defined.  Such  a  buffer 
would  need  to  differentiate  i  and  j  and  remember  their  arrival  sequence  to  generate  o  and 
o  .  p  appropriately.  That  model  is  relatively  complex  and  does  not  contribute  to  the 

present  discussion. 

One  can  also  build  the  two-token  buffers  structurally  from  the  one -token  buffers 

2 

using  Parallel  Composition.  Call  these  composites  FPF,  GPG.~ 


2  Think  of  ‘P’  as  representing  “parallel.” 
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def 

FPF  =  (F\m/o]\F\m/i])\m  (5-6) 

GPG  =  (G[x/o,m/p]\G[m/i])\m  (5-7) 

Note  that  the  seven  reference  models  F,  G,  FI,  GG,  FF,  FPF  and  GPG  can  be 
assembled  into  a  structure  that  is  ordered  upon  the  congruent  weak  conformance 
relationship,  where  the  arrows  point  from  implementation  to  specification.  First  of  all, 
one  has  G  F  because  G’s  output  p  is  extraneous  to  F.  For  the  same  reason, 

GG  hw  FF.  Now  //  >-w  G  because  input  j  is  extraneous  to  G  and  because  the  lone 
sequence  o.p  is  a  sufficient  implementation  the  maxoctset  of  G’s  maxoctset  {o.p, 
p.o  } .  Furthermore,  FF  yw  F  and  GG  >-w  G  because  the  additional  states  of  FF  and  GG 
that  accept  a  second  token  are  unreachable  by  F  and  G.  Also  GPG  GG.  Two  of  the 
models  are  in  fact  observationally  congruent:  FPF  =  FF.  For  them,  the  >-w  relationship  is 
bi-directional. 

By  the  transitivity  of  hw  one  can  follow  the  arrows  and  infer  all  pairs  that  share 

the  hw  relationship.  Thus  all  the  agents  are  seen  to  conform  to  F  and  thus  F  is  a  greatest 

lower  bound  or  least  specification.  However  the  diagram  is  not  a  lattice  and  there  is  no 
greatest  implementation.  In  the  absence  of  H,  however,  GPG  would  fulfill  that  role. 

GPG  — >  GG  — >  FF  =  FPF 

I  i 

H  — >  G  — >  F 

Figure  5-1.  Confonnance  Structure  for  the  Reference  Models 

These  seven  reference  models  now  inspire  the  initial  models.  The  initial  models 
are  VHDL  state  machines.  One  starts  with  the  entity  declaration  for  F: 
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entity  F  is 

(  I  :  in  bit;  0  :  out  bit  ) 
end  F; 


For  simplicity,  all  signals  are  of  type  bit.  These  signals  will  become  lower  case  action 
labels  after  translation,  with  those  of  mode  out  receiving  an  overbar  or  leading 
apostrophe.  However,  an  unaccompanied  entity  declaration  is  incomplete  and  gives  only 
the  sort  of  an  agent.  One  needs  an  entity-architecture-configuration  triple  to  extract  a  full 
agent  definition.  Such  a  triple  is  called  a  VHDL  design  unit. 

--  Initial  Model  for  One-token  Buffer  F 
entity  F  is 

(  I  :  in  bit;  0  :  out  bit  ) 
end  F; 

architecture  BEHAVIOR  of  F  is 
begin 

process  ( I ) 
begin 

0  <=  not  0; 
end  process; 
end  BEHAVIOR; 

configuration  CFG_F  of  F  is 
for  BEHAVIOR- 
end  for; 
end  CFG  F; 


The  configuration  body  tells  the  VHDL  analyzer  what  design  units  to  use  for  the 
subcomponents  of  an  architecture.  However,  purely  behavioral  models  such  as  this  one 
have  no  subcomponents,  and  their  configuration  is  trivial.  In  such  cases  the  designer  is 
not  required  to  supply  a  configuration — the  VHDL  analyzer  will  create  a  default 
configuration.  Default  configurations  will  be  assumed  for  the  remaining  behavioral 
models. 
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Like  most  CCS  agents,  VHDL  processes  are  reactive.  The  behavior  in 
process  (I)  above  accepts  an  input  I,  generates  an  output  O,  then  evolves  to  repeat  this 
cycle  forever. 

Since  the  output  transition  occurs  strictly  later  (by  one  delta)  than  the  input,  the 
behavior  of  F  readily  translates  to  a  CCS  target  model: 


F=i.o.F  (5-8) 


A  pattern  can  be  discerned  already.  A  signal  on  a  process  sensitivity  list,  which 
must  be  an  input,  translates  into  the  “leadoff’  action  of  a  sequential  CCS  term. 
Assignments  within  the  body  of  a  process  create  output  actions  that  are  appended  to  that 
tenn.  The  end  process  statement  then  denotes  the  point  at  which  the  behavior  evolves 
back  to  the  root  agent. 

Now  consider  the  initial  model  for  G: 


--  Initial  Model  for  One-token  Buffer  G 
entity  G  is 

(  I  :  in  bit;  0, P  :  out  bit  ) 
end  G; 

architecture  BEHAVIOR  of  G  is 
begin 

process  ( I ) 
begin 

0  <=  not  0; 

P  <=  not  P; 
end  process; 
end  BEHAVIOR; 


The  transactions  on  O  and  P  are  scheduled  at  the  same  simulation  time,  one  delta 
after  the  present.  In  fact,  they  are  simultaneous.  Simultaneity  cannot  be  expressed  in 
CCS  so  concurrency  will  have  to  suffice.  Thus,  the  process  unfolds  into  the  target  model 


5-10 


(5-9) 


G  =  i.(  o  |  p  ).G 


The  translator  must  detect  when  VHDL  transactions  are  scheduled  at  the  same  time,  and 
translate  them  as  a  concurrent  (  o  \  p  )  and  not  a  sequential  o.p. 

The  buffer  G  forms  an  excellent  example  of  how  the  differing  semantics  result  in 
imperfect  translation.  The  concurrency  of  the  CCS  model  says  only  that  the  order  of 
actions  is  indetenninate.  The  CCS  model  is  thus  looser  than  the  VHDL  model,  which 
specifies  that  the  events  are  simultaneous. 

Here  is  the  initial  model  for  H. 


--  Initial  Model  for  One-token  Buffer  H 


entity  H  is 

(  I,J:  in  bit;  0, P  :  out  bit  ) 
end  H; 

architecture  BEHAVIOR  of  H  is 
begin 

process ( I , J) 
begin 

if  event ' I  then 
0  <=  not  0; 

P  <=  not  P  after  delta; 
else  if  event ' J  then 
0  <=  not  0; 
end  if; 
end  process; 
end  BEHAVIOR; 


Here  the  assignment  to  P  is  delayed  an  additional  delta  to  insure  it  occurs  strictly 
later  than  the  assignment  to  O.  Thus  the  O  transaction  is  scheduled  one  delta  after  the 
present,  and  the  P  transaction  two  deltas  later. 

The  modeling  of  the  inputs  of  H  exhibits  another  difficulty  in  matching  the 
semantics  of  CCS  and  VHDL.  In  the  CCS  reference  model  the  inputs  block  each  other. 
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The  first  input  to  arrive  forces  a  commitment  to  one  branch  of  behavior,  and  the  other 
input  cannot  be  received.  If  the  two  inputs  arrive  simultaneously  then  one  input  is 
arbitrarily  accepted  and  the  other  blocked.  In  VHDL,  when  events  occur  on  both  I  and  J 
at  the  same  time,  both  can  be  accepted,  and  each  can  then  trigger  output  transactions.  In 
fact,  one  course  of  action  can  be  denoted  for  I,  a  second  course  of  action  for  J,  and  a  third 
course  of  action  (not  simply  a  combination  of  the  first  two)  can  be  denoted  when  I  and  J 
arrive  together.  However,  the  idea  that  I  and  J  arriving  together  can  trigger  behavior 
completely  different  is  not  natural  for  hardware,  especially  for  asynchronous  hardware. 
Though  unlikely  to  occur,  such  behavior  is  nonetheless  expressible  in  VHDL,  though  not 
in  CCS.  A  CCS  tool  may  be  able  to  detect  a  blocked  input  and  raise  an  exception,  but  the 
language  itself  does  not  allow  simultaneous  activation  of  both  branches.  Thus,  here  is  a 
rare  feature  that  cannot  be  translated.  In  the  initial  (VHDL)  code  for  H,  the  designer  has 
avoided  such  difficulty  by  favoring  J  over  I,  allowing  only  one  branch  of  behavior  even  if 
both  inputs  arrive.  This  still  departs  from  the  intent  of  the  CCS  reference  model,  where  i 
is  equally  likely  to  be  favored  over  j. 

The  failure  to  capture  in  VHDL  all  the  nuances  of  the  CCS  reference  models  is 
not  surprising,  given  the  semantic  differences.  For  the  present  study  however,  translation 
in  this  direction  is  not  an  issue.  The  question  is  this:  given  a  VHDL  model,  can  a  CCS 
model  be  constructed  that  preserves  enough  infonnation  such  that  meaningful 
verifications  can  be  performed?  The  focus  now  is  how  to  extract  CCS  behavior  from 
the  initial  VHDL  models  given  thus  far. 

The  ability  to  extract  state  machine  behavior  from  a  VHDL  process  is  critical  to 
the  translation.  Once  a  process  is  recast  as  a  state  machine,  it  can  be  directly  mapped  to  a 
CCS  agent.  The  state  machine  extraction  algorithm  follows: 

(1)  Start  at  the  root  state. 

(2)  Consider  all  possible  input  events,  as  well  as  the  possibility  of  no  input. 
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(3)  Update  the  output  drivers  with  any  new  transactions. 

(4)  Advance  the  clock  to  the  next  transaction. 

(5)  Conduct  the  appropriate  output  events.  Simultaneous  outputs  are  translated  as 
concurrent  rather  than  simultaneous. 

(6)  Remove  the  transpired  transactions  from  the  drivers. 

(7)  Characterize  the  new  state  by  the  residual  transactions  on  the  drivers. 

(8)  Return  to  (2)  and  repeat  until  the  entire  behavior  is  expanded. 


The  algorithm  mimics  the  VHDL  simulation  cycle,  collecting  the  sequence  of 
states  and  events  as  it  does  so.  By  so  mimicking  the  simulation  cycle,  it  faithfully 
captures  the  relative  order  of  events  intended  by  the  VHDL  model — except  that 
simultaneous  events  are  translated  as  merely  concurrent.  Since  existing  VHDL 
simulators  can  manage  the  states,  events  and  transactions  of  the  simulation  cycle,  it  is 
clearly  feasible  to  assume  the  same  capability  can  be  incorporated  into  a  VHDL-to-CCS 
translator. 

The  algorithm  characterizes  states  by  the  content  of  the  signal  drivers.  The  root 
state  is  quiescent,  having  no  transactions  scheduled.  Applied  to  the  VHDL  model  of  the 
process  within  H,  the  results  of  this  algorithm  appear  in  the  following  Tables: 


Table  5  - 1 .  Expansion  of  HO 


state 

HO 

0(0) 

P(0) 

input 

i 

./ 

update  drivers 

O(0,l@lA) 

0(0,1  @1  A) 

P(0,1  (2j2A) 

P(0) 

advance  clock 

A 

A 

output 

o 

o 

new  state 

HI 

HO 

0(1) 

0(1) 

P(0,1@1A) 

P(0) 
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Starting  at  the  root  state,  here  called  HO,  the  outputs  are  given  arbitrary  starting 
values  of  ‘O’.  Though  the  transitional  semantics  of  CCS  does  not  assign  level  values,  the 
algorithm  must  track  level  values  to  properly  maintain  the  drivers  of  O  and  P.  Two 
branches  of  input  behavior  exit  state  H,  the  left-hand  branch  for  the  arrival  of  i  and  the 
right-hand  branch  for  j.  The  possibility  of  no  input  need  not  be  considered  for  a 
quiescent  state  such  as  H.  The  arrival  of  i  and  j  simultaneously  is  also  not  considered. 
Since  CCS  cannot  model  this  simultaneous  arrival  of  inputs,  one  accepts  this  as  a 
limitation  of  the  translator. 

For  each  behavioral  branch,  the  drivers  are  updated  and  expressed  in  the 
following  format: 

<name>(<current  value>,  <transaction>,  <transaction>,  . . .  ) 

where  each  transaction  is  of  the  form 

<new  value>@<time> 

After  the  drivers  are  updated  the  clock  then  advances  to  the  next  scheduled 
transaction.  In  both  branches  this  increment  is  one  delta,  and  the  resulting  event  is  on  O 
in  both  cases,  so  an  output  o  occurs.  The  residual  drivers  then  characterize  the  new 
states.  The  right-hand  branch  has  no  transactions  remaining,  and  it  is  recognized  to  be 
the  root  state  HO.  The  fact  that  O  now  has  current  value  of  ‘1’  instead  of  ‘0’  is 
immaterial  to  the  CCS  transitional  semantics,  so  this  branch  of  behavior  need  not  be 
further  expanded.  For  the  left-hand  branch,  the  pending  transaction  on  P  is  brought  one 
delta  nearer  in  time,  and  the  resulting  state  called  HI  is  characterized  by  the  one 
transaction  on  P  scheduled  for  the  next  delta. 


3  This  is  only  true  when  all  the  assignments  are  in  the  pseudo-transitional  style.  In  general  the  translator 
will  need  to  expand  behavior  until  both  the  level  values  as  well  as  the  drivers  match  some  previous  state. 
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The  CCS  behavior  of  state  HO  can  now  be  derived  directly  from  this  table,  where 
the  actions  in  parallel  columns  are  connected  by  Choice,  and  the  actions  flowing  down  a 
single  column  are  connected  sequentially: 


HO  =  i.  o  .HI  +  j.  o  .HO 


(5-10) 


State  HI  merits  further  expansion: 


Table  5-2.  Expansion  of  HI 


state 

HI 

0(1) 

P(0,1@1A) 

input 

i 

./ 

none 

update  drivers 

O(l,0@lA) 

O(l,0@lA) 

0(1) 

P(0, 1  @  1  A,  1  @2  A) 

P(0,1@1A) 

P(0,1@1A) 

advance  time 

A 

A 

A 

output 

(o\p) 

(o  \p) 

P 

new  state 

H2 

HO 

HO 

0(0) 

0(0) 

0(1) 

P(U(2>,1A) 

P(l) 

P(l) 

State  HI  is  not  quiescent.  Having  one  pending  transaction  on  P,  the  possibility  of 
an  event  on  P  ahead  of  further  inputs  must  also  be  considered.  Hence  there  are  three 
branches  to  consider.  For  the  left-hand  branch,  transactions  to  both  O  and  P  are  posted. 
The  updated  driver  for  P  has  two  transactions  to  the  same  value,  but  at  different  times  (1A 
and  2A).  According  to  the  VHDL  semantics  for  inertial  signals,  when  two  transactions 
on  a  signal  are  to  the  same  level  value,  both  remain  on  the  driver  (Bhasker,  1999:98). 
The  second  transaction  may  be  ineffective  in  producing  a  real  signal  change  in  P.  Such 
transactions  must  be  maintained,  however,  in  case  an  intervening  event  changes  the  value 
of  P.  When  the  clock  advances  one  delta,  transactions  for  both  O  and  P  are  encountered, 
and  the  simultaneous  events  are  translated  as  the  concurrent  output  (  o  \  p  ).  One  residual 
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transaction  remains  on  P’s  driver,  and  the  new  state  is  called  H2.  For  the  center  branch. 


( o  |  p )  is  again  generated,  and  the  resulting  state  matches  HO  under  transitional 

semantics.  The  right  hand  branch,  receiving  no  inputs  by  the  time  the  clock  advances, 
simply  emits  the  p  and  arrives  at  the  quiescent  state  II.  The  CCS  model  for  HI  is  thus 


def 

HI  =  i.(o  |  p  ).H2  +  j.(o  \p).H0  +  p  .HO  (5-11) 


H2  is  now  expanded: 


Table  5-3.  Expansion  of  H2 


state 

H2 

0(0) 

P(U@1A) 

input 

i 

./ 

none 

update  drivers 

0(0,1@1A) 

0(0,1@1A) 

0(0) 

P(  1  ,4-@4-A,0(o)2A) 

P(U(5)1A) 

P(U@1A) 

advance  time 

A 

A 

A 

output 

o 

o 

none 

new  state 

HI 

HO 

HO 

0(1) 

0(1) 

0(1) 

P(1,0(2)1A) 

P(l) 

P(l) 

The  analysis  for  H2  is  straightforward  in  the  center  branch.  The  left-hand  branch, 
however,  has  a  curiosity.  Here  again  P  has  transactions  posted  at  one  delta  and  two 
deltas.  This  time  the  transactions  conflict.  When  the  assignment  is  to  a  different  level 
value,  the  first  transaction  is  deleted,  per  the  semantics  of  inertial  signals  (Bhasker, 
1999:97).  Hence,  when  o  is  emitted,  the  center  branch  arrives  at  a  state  with  one 
transaction  pending  on  P.  This  state  is  recognized  to  be  identical  to  HI  under  transitional 
semantics.  The  right  hand  branch  also  shows  a  curiosity.  When  no  inputs  are  received, 
the  transaction  on  P  transpires,  but  the  event  driving  P  to  ‘1’  is  ineffective  since  P  is 
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already  at  ‘1’.  No  actual  transition  occurs,  and  H2  decays  to  //without  receipt  of  input 
or  generation  of  output. 


H2  =  i.  o  .HI  +  j.  o  .HO  +  HO  (5-12) 

Once  the  process  rooted  at  HO  has  been  completely  expanded  the  algorithm 
tenninates.  Since  the  initial  model  H  had  but  one  process,  the  target  model  H  is 
identified  with  this  one  process:  H  =  HO. 

In  summary,  one  now  has  is  a  mechanical  means  to  produce  a  CCS  state  machine 
(target  model)  from  a  VHDL  process.  This  algorithm  expanded  the  single  process  within 
//rather  quickly  since  all  the  output  delays  are  deltas.  It  could  become  extremely  busy  if 
one  of  the  delays  were  finite,  say,  1  nanosecond.  One  might  have  to  entertain  the 
possibility  of  new  inputs  arriving  every  delta,  of  which  there  are  an  infinite  number  in  the 
space  of  a  nanosecond.  Such  intractability  forces  the  designer  to  consider  whether  inputs 
will  realistically  arrive  every  delta,  and,  if  not,  to  properly  annotate  his  VHDL  with  assert 
statements,  tests,  etc.,  to  properly  limit  the  code  in  accordance  with  the  system  it  purports 
to  model. 

Consider  now  initial  models  for  the  behavioral  two-token  buffers  FF  and  GG. 
The  reference  models  for  these  buffers  admit  nondeterminism  due  to  the  race  between  the 
generation  of  the  first  output  and  the  receipt  of  the  second  input.  The  environment 
controls  the  arrival  of  the  input,  but  the  model  controls  the  emission  of  the  output.  CCS 
is  indefinite  about  output  emission,  allowing  it  to  occur  anytime  in  the  near  or  distant 
future.  One  can  model  such  indefinite  emission  in  VHDL  by  implementing  a  random 
number  generator  to  assign  delays,  but  it  is  unnatural  and  contrived  to  do  so.  Normally, 
the  VHDL  model  uses  typical  or  worst  case  delays.  These  delays,  arising  from  solid- 
state  circuitry,  are  certainly  orders  of  magnitude  less  than  the  decades  or  centuries  that 
the  CCS  model  allows.  Thus  for  the  initial  models,  fixed  delays  will  suffice. 
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Now  a  two-token  buffer  can  accept  two  inputs  without  generating  an  output,  but 
not  three.  In  the  following  VHDL  initial  model  the  third  output  will  be  disallowed  with 
an  assert  statement  in  the  body  of  the  main  process. 


--  Initial  Model  for  Two-token  Behavioral  Buffer  FF 
entity  FF  is 

(  I  :  in  bit;  0  :  out  bit  ) 
end  FF; 

architecture  BEHAVIOR  of  FF  is 

constant  DELAY1,  DELAY2  :  time; 
signal  STATE  :  (EMPTY_0 ,  HALF_0 ,  FULL_0, 

EMPTY_1,  HALF_1 ,  FULL^l )  :=  EMPTY_0 ; 

begin 

process  ( I ) 
begin 

assert  (not (STATE  =  EMPTY_0  or  STATE  =  EMPTY_1 ) 

and  I ' event 


case  STATE  is 

when  EMPTY_0  => 

0  <=  1  after  DELAY1 ; 

STATE  <=  HALF_0 ,  EMPTY_1  after  DELAY1 ; 
when  HALF_0  => 

0  <=  1  after  DELAY2 ; 

STATE  <=  FULL_0 ,  HALF_1  after  DELAY2 ; 
when  EMPTY_1  => 

0  <=  0  after  DELAY1 ; 

STATE  <=  HALF_1,  EMPTY_0  after  DELAY1 ; 
when  HALF_1  => 

0  <=  0_ af ter  DELAY2 ; 

STATE  <=  FULL_1,  HALF_0  after  DELAY2 ; 
end  case; 
end  process; 
end  BEHAVIOR; 


DELAY1  and  DELAY2  are  constants  of  type  time.  Their  values  are  not  given 
here,  but  would  be  specified  by  the  designer.  An  internally  declared  STATE  signal 
tracks  state  infonnation.  STATE  must  be  a  VHDL  signal,  and  not  a  variable,  because  a 
state  change  must  be  a  scheduled  future  transaction  that  can  be  retracted. 
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This  time,  for  variety,  explicit  level-signal  assignments  are  used  instead  of  the 
pseudo-transitional  assignments  of  the  single-token  models.  A  STATE  signal  is  also 
used.  STATE  takes  on  six  possible  values.  Normally,  one  expects  a  two-token  buffer  to 
have  three  states:  empty,  half-full  and  full.  With  O  receiving  level  assignments,  the  two 
possible  values  for  O  double  the  state  possibilities. 

The  state  machine  extraction  algorithm  executes  just  as  well  with  level 
assignments: 


Table  5-4.  Expansion  of  FFO 


state 


input 
update  drivers 

advance  clock 
output 

new  state 


FFO 

STATE(EMPTY_0) 

0(0) 


STATE(EMPT  Y_0,HALF_0@A,EMPT  Y_1  @DEL  AY  1 ) 

_ 0(0,  1@DELAY1) _ 

A 


none 


FF1 

STATE(HALF_0,EMPTY_  1  @DEL  AY  1 ) 
0(0,  1@DELAY1) 


Table  5-5.  Expansion  of  FF1 


state 


input 

update 

drivers 

adv. 

clock 

output 

new 

state 


FF1 

STATE(HALF  0, EMPTY  1@DELAY1) 

0(0,  1@DELAY1) 

/ 

none 

STATE(HALF  O.FULL  0@A,HALF  1@DELAY2 

STATE(HALF  0, EMPTY  1@DELAY1) 

) 

0(0,  1@DELAY1) 

0(0,  1@DELAY2) 

A 

DELAY 1 

None 

O 

FF2 

FF3 

STATE(FULL  O.HALF  1@DELAY2) 

STATE(EMPTY  1) 

0(0,  1@DELAY2) 

0(1) 
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The  state  machine  behavior  can  continue  to  be  expanded.  Since  the  signal 
STATE  contains  all  necessary  state  information,  the  system-generated  state  labels  FF_x 
are  unneeded,  and  the  six  possible  values  of  STATE  can  be  used  for  state  labels.  This 
yields  the  following  target  model: 


FF  =  EMPTY _0  =  i.HALFO 

HALFO  =  i.FULL  O  +  o  .EMPTY _1 

FULL  O  =  o  .HALF _1 

EMPTY  1  =  i.HALFl 

HALF1  =  i.FULLl  +  o  .EMPTY  0 

FULLJ  =  o  .HALF  O  (5-13) 


The  initial  and  target  models  for  GG  are  similar  to  those  of  FF  with  transitions  on 
P  simultaneous  with  those  on  O  (in  the  initial  model)  and  concurrent  (in  the  target 
model): 


--  Initial  Model  for  Two-token  Behavioral  Buffer  GG 
entity  GG  is 

(  I  :  in  bit;  0,  P  :  out  bit  ) 
end  FF; 

architecture  BEHAVIOR  of  GG  is 

constant  DELAY1,  DELAY2  :  time; 
signal  STATE  :  (EMPTY_0 ,  HALF_0 ,  FULL_0, 

EMPTY_1,  HALF_1 ,  FULL_1 )  :=  EMPTY_0 ; 

begin 

process  ( I ) 
begin 

assert  (not (STATE  =  EMPTY_0  or  STATE  =  EMPTY_1 ) 

and  I ' event  ) ; 

case  STATE  is 

when  EMPTY_0  => 

0  <=  1  after  DELAY1 ; 

P  <=  1  after  DELAY1 ; 

STATE  <=  HALF  0,  EMPTY  1  after  DELAY1 ; 
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when  HALF_0  => 

0  <=  1  after  DELAY2 ; 

P  <=  1  after  DELAY2 ; 

STATE  <=  FULL_0 ,  HALF_1  after  DELAY2 ; 
when  EMPTY_1  => 

0  <=  0  after  DELAY1 ; 

P  <=  0  after  DELAY1 ; 

STATE  <=  HALF_1,  EMPTY_0  after  DELAY1 ; 
when  HALF_1  => 

0  <=  0_after  DELAY2 ; 

P  <=  0  after  DELAY2 ; 

STATE  <=  FULL_1,  HALF_0  after  DELAY2 ; 
end  case; 
end  process; 
end  BEHAVIOR; 


GG  =  EMPTY _0  =  i.HALFO 

HALF  O  =  i.FULL  O  +  (o\p  ).EMPTY_1 
FULL  O  =  (o\p  ).HALF_1 

EMPTY _1  =  i.HALFJ 

HALFJ  =  i.FULL  J  +{o\p  ).EMPTY_0 

FULL  J  =  (o\p  ).HALF_0  (5-14) 


In  general,  the  algorithm  translates  one  VHDL  process  into  one  CCS  agent.  The 
initial  models  given  thus  far  have  used  single-process  behavioral  architectures.  Indeed, 
there  can  be  two  or  more  processes  within  a  behavioral  architecture.  When  that  happens 
a  state  machine  is  generated  for  each  separately,  and  Parallel  Composition  connects  them, 
since  coexisting  processes  are  considered  parallel  occurrences  in  VHDL.  If  such 
processes  are  totally  independent,  having  no  common  input  in  their  sensitivity  lists,  then 
the  simple  Parallel  Composition  suffices.  If  processes  share  a  common  sensitive  signal, 
this  cannot  be  directly  modeled  in  CCS  since  multiple  connections  to  a  single  port  are  not 
allowed.  As  discussed  above,  this  limitation  is  imperfectly  overcome  by  using  a  FORK 
element  to  split  the  signal. 
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(5-15) 


FORK  =  i.o.p  .FORK 

Now  using  the  notation  [[(']]  to  denote  “the  CCS  translation  of  VHDL  construct  V,”  one 
has  that 

process ( I , J) 

end  process; 
process ( I , K) 

end  process; 

translates  to 

(  FORK[ml/o,m2/p\  |  [[process  ( I ,  J) ... 

|  [[process  ( I ,  K) ...;  ]\[m2/k\  )\{ml,m2 }  (5-16) 

Now  structural  VHDL  models  contain  components,  and  those  components  will  be 
treated  just  like  multiple  processes,  i.e.,  they  are  concurrent  and,  upon  translation,  are 
connected  by  Parallel  Composition.  Consider  the  initial  models  for  the  structural  two- 
place  buffers.  First,  consider  FPF: 

--  Initial  Model  for  Two-token  Structural  Buffer  FPF 
entity  FPF  is 

port (  I:  in  bit;  0:  out  bit); 
end  FPF; 

architecture  STRUCTURE  of  FPF  is 
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component  F 

port (  I  :  in  bit;  0  :  out  bit); 
end  component; 
signal  M  :  bit; 
begin 

U1:F  port  map(I=>I,  0  =>M)  ; 

U2:F  port  map(I=>M,  0=>0) ; 
end  STRUCTURE; 

configuration  CFG_FPF  of  FPF  is 
for  STRUCTURAL 

for  all:  F  use  configuration  WORK . F . BEHAVIOR; 

end  for; 
end  for; 
end  CFG  FPF; 


Being  a  structural  VHDL  model,  the  initial  model  for  FPF  must  contain  an 
explicit  configuration  body  to  import  models  for  the  subcomponents  F.  Note  how  this 
configuration  calls  out  the  default  configuration  for  F,  which  is  known  as 
“WORK.F.behavior”  in  this  implementation. 

This  model  also  contains  an  internal  signal  M.  M  is  not  a  state  signal,  but  an 
internal  node  to  which  component  pins  are  attached.  The  components  within  the  model 
are  concurrent  and  connected  by  Parallel  Composition  upon  translation.  The  port  maps 
for  the  Ul,  U2  components  translate  directly  into  Relabeling  functions  in  CCS.  Any 
internally  declared  signal,  such  as  M  here,  is  restricted  upon  translation.  Thus,  the  target 
model  for  FPF  is 


FPF  =  F\m/o\  |  F[m/i\  \  {  m } 


(5-17) 


The  initial  model  for  GPG  is  similar  to  FPF: 


--  Initial  Model  for  Two-token  Structural  Buffer  GPG 
entity  GPG  is 

port (  I:  in  bit;  0,P:  out  bit); 
end  GPG; 
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architecture  STRUCTURE  of  GPG  is 
component  G 

port (  I  :  in  bit;  0, P  :  out  bit); 
end  component; 
signal  M  :  bit; 
begin 

U1:G  port  map (I  =>I,  0=>open,  P=>M) ; 

U2:G  port  map(I=>M,  0=>0,  P=>P) ; 
end  STRUCTURE; 

configuration  CFG_GPG  of  GPG  is 
for  STRUCTURAL 

for  all:  G  use  configuration  WORK . G . behavior ; 
end  for; 
end  for; 
end  CFG  GPG; 


Within  GPG  resides  an  open  port  assignment  for  Ul.  This  unconnected  pin  is 
destined  to  become  an  extraneous  output  upon  translation.  Unlike  the  VHDL  model, 
which  hides  this  unconnected  pin,  the  CCS  model  maintains  it  as  an  explicit,  though 
extraneous,  output  action. 


GPG  =  (  G[x/o,  m/p]  |  G[m/i\  )\{m}  (5-18) 

The  time  has  now  arrived  to  capture  VHDL-to-CCS  translation  rules  that  target 
the  “pure”  version  of  CCS  (with  interleaving  concurrency).  The  VHDL  subset  supported 
by  the  hypothetical  translator  is  quite  broad,  since  all  the  capability  of  a  VHDL  simulator 
is  presumed  for  the  state  machine  extractor.  Indeed,  a  reasonable  way  to  build  such  a 
translator  would  use  modify  an  existing  VHDL  analyzer  and  simulator  as  a  front  end. 
Thus,  explicit  and  implicit  processes  are  supported.  Implicit  and  literal  sensitivity  lists 
are  supported,  as  well  as  other  process  initiation  schemes  such  as  the  wait  statement. 
Both  inertial  and  transport  delay  are  supported,  as  well  as  both  transitional  and  level 
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value  assignments.  All  control  structures  such  as  case,  if  ...  then  ...else,  block  and  so 
forth  are  supported. 

In  the  discussion,  all  signals  were  of  either  of  type  bit,  or  are  of  enumerated  type. 
This  suffices  since  more  complex  structures  can  be  built  from  assemblies  of  bits.  Modes 
in  and  out  are  the  only  modes  supported  by  the  translation.  Other  modes,  such  as  inout 
and  buffer,  can  be  recast  as  in  and  out  with  a  little  effort.  The  generate  statement, 
packages,  and  a  host  of  other  features  are  not  directly  supported,  but  these  constructs  are 
typically  pre-elaborated  and  result  in  constructs  that  are  supported. 

5.4  VHDL  to  CCS  Translation  Rules 

Ten  rules  governing  VHDL-to-CCS  translation  are  now  presented.  Of  these,  the 
most  significant  rule  is  the  state  machine  extraction  algorithm,  Rule  9. 

(1)  Each  VHDL  design  unit  (entity-architecture-configuration  triple)  is  translated  into 
a  unique,  capitalized  name  according  to  the  scheme: 

Design  Unit  Name  ::=  <Entity  Name> ^Architecture  Name> ^-Configuration  Name> 

This  naming  convention  is  possible  because  all  three  items  are  required  to  have  a 
design  unit.  Lone  entities  do  not  convey  enough  information  for  translation.  In 
cases  where  the  VHDL  analyzer  would  normally  supply  a  default  configuration, 
that  configuration  is  literally  called  “Default”  within  the  CCS  name.4 

(2)  Each  process  within  a  design  unit  is  translated  into  a  unique  capitalized  CCS 
agent  name  according  to  the  scheme: 

4  The  automated  naming  schemes  given  here  tend  to  yield  verbose  names.  For  brevity,  these  schemes  were 
not  followed  in  the  examples.  For  example,  HO  in  Table  5-1  would,  under  these  rules,  have  received  the 
more  cumbersome  designation  of  H_Behavior_Default_0. 
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Process  Name  ::=  <Design  Un it  Nam <?>_ P ro c c s s< v eqii ence  number> 

For  a  lone  process  within  a  design  unit,  the  “_VrocQSS<sequence  number >” 
appendage  is  omitted. 

(3)  Each  VHDL  signal  is  translated  into  a  unique  lower-case  CCS  action  name,  with 
the  design  unit  infonnation  appended  to  assure  uniqueness: 

signal  name  ::=  []<design  unit  name  ( lower  case)>_<vhdl  signal  name> 

A  leading  apostrophe  is  added  for  signals  of  mode  out.  Any  apostrophe 
appearing  in  VHDL  names  is  translated  literally  as  “  tick  ”  to  avoid  confusion 
with  the  CCS  apostrophe. 

(4)  Locally  declared  signals  used  behaviorally  (not  connected  to  component  ports)  are 
recognized  as  state  signals  and  are  translated  into  multiple  CCS  agents — one 
agent  for  each  state  value  used.  The  naming  scheme  is 

State  Name  ::=  <Design  Unit  Name>_<VHDL  Local  Signal  Name>_<State  Value> 

(5)  State  signals  created  by  the  state  machine  extraction  algorithm  (Rule  5)  are  given 
names  according  to  the  scheme: 

State  Name  ::=  <Process  Name>_<sequence  number> 
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(6)  Locally  declared  signals  appearing  in  structural  models  are  internal  signals 
recognized  because  they  connect  to  component  ports.  Their  translation  is  to 
actions.  The  naming  convention  for  the  action  is 

local  action  name  ::=  <design  unit  name(Iower  case)> _<vhdl  local  signal  name> 

When  multiply  connected,  they  are  modeled  as  FORKs,  with  the  FORK  outputs 
receiving  an  “_<sequence  number >”  appendage  added  to  the  local  action  name. 
Upon  translation,  these  names  are  added  to  the  Restriction  set  of  the  translated 
structural  agent  that  contains  the  FORK. 

(7)  Port  maps  translate  into  Relabeling  functions.  Thus  /=>  M becomes  \m/i\. 

(8)  A  port  assignment  to  open  indicates  an  unconnected  pin.  The  pin  becomes  an 
extraneous  output  and  gets  relabeled  in  CCS  to  avoid  collision.  It  does  not  get 
hidden  as  it  does  in  the  VHDL  model.  The  translator  is  again  presumed  to  have 
an  unlimited  supply  of  spare  names  to  handle  these  cases.  The  fonnat  of  this 
name  is  a  lower  case  output  name  with  a  prefixed  apostrophe: 

'<design  unit  name>_<translator-supplied  symbol> 

where  the  translator-supplied  symbol  is  different  than  any  other  user-defined 
symbol  in  the  design  unit. 

(9)  Processes  are  translated  to  CCS  state  machines  by  means  of  the  state  machine 
extraction  algorithm. 
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(1)  Start  at  the  root  state. 

(2)  Consider  all  possible  input  events,  as  well  as  the  possibility  of  no  input. 

(3)  Update  the  output  drivers  with  any  new  transactions. 

(4)  Advance  the  clock  to  the  next  transaction. 

(5)  Conduct  the  appropriate  output  events.  Any  simultaneous  outputs  are 
translated  as  concurrent. 

(6)  Remove  the  transpired  transactions  from  the  drivers. 

(7)  Characterize  the  new  state  by  the  residual  transactions  on  the  drivers. 

(8)  Return  to  (2)  and  repeat  until  the  entire  behavior  is  expanded. 

(10a)  Multiple  processes  within  a  design  unit  that  have  no  sensitive  signals  in 

common  become  concurrent  CCS  agents  joined  by  Parallel  Composition. 

process  ( I ) 
begin 

end  process; 

process ( J) 
begin 

end  process; 

translates  into: 

[[process  (I) ...;]]  |  [[process  (J) ...;]] 

(10b)  When  multiple  processes  within  a  design  unit  share  the  same  sensitive  signals, 
they  are  translated  into  a  Parallel  Composition  with  FORK  agents  added  to  split 
the  input  for  separate  communication  with  each  agent.  The  translation  of 
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process ( I , J) 
begin 

process  body  1> 
end  process; 

process ( I , K) 
begin 

<process  body  2> 
end  process; 


is 


(  [[process  ( I ,  J) ...;  ]\[midl/i\ 
[[process  ( I ,  K)  ]][mid2/j] 

|  FORK [midl/o,mid2/p] 

)\{midl,  mid2 } 


where  midi  and  mid2  are  drawn  from  an  unlimited  supply  of  extra  names  that  the 
translator  is  presumed  to  have. 


(10c)  The  units  or  components  instantiated  in  a  structural  model  are  combined  by 
Parallel  Composition  upon  translation.  When  such  components  share  a  common 
input  signal,  that  signal  is  modeled  as  a  FORK  in  the  same  manner  as  the 
multiply-sensitive  signals  in  Rule  9. 


Rules  10a,  10b  and  10c  are  really  special  cases  of  a  more  general  rule  that  can  be  applied 
to  models  that  employ  a  mixed  behavioral/structural  style.  Hence  they  are  combined  as 
Rule  10: 


(10)  A  design  unit  is  translated  by  identifying  its  CCS  name  with  the  Parallel 
Composition  of  its  contained  processes  and  components.  To  wit. 


<Design  Unit  Name>  = 

(  [[process,]]  [/,]  |  [[process,]] \f2]  |  ...  |  [[process;]] [/a] 
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|  [[component,]]  [g,] 

|  [[component,]]  [g,]  |  .. 

.  |  [[component,,,]]  [g,„] 

|  FORK, 

|  FORK,  |  . 

..  |  FORK,, 

)\{internal  signals  and  their  FORKed  branches} 


The  FORKs  are  created  and  inserted  as  necessary  to  split  multiply-connected  internal 
nodes.  The  Relabeling  functions  f  and  g,  reassign  sensitive  signal  names  (for 
processes)  and  port  names  (for  components)  to  receive  the  FORK  outputs.  All 
internal  signals  are  then  restricted. 

The  translation  of  components  represents  a  recursive  application  of  Rule  10,  since 
components  are  in  turn  design  units  themselves.  The  recursion  terminates  when  purely 
behavioral  design  units  (containing  only  processes)  are  encountered. 

In  summary,  the  first  eight  rules  govern  the  translation  of  names.  Rule  9  shows 
how  to  translate  processes.  Rule  10  shows  how  to  translate  structures  recursively,  until 
only  processes  are  encountered. 

Note  how  Rule  10  is  be  exceedingly  liberal  in  its  use  of  FORKs  to  support  the 
pure  CCS  semantics.  The  resulting  CCS  code  is  ungainly  and  probably  impractical  for 
all  but  the  simplest  verifications.  However,  this  necessity  emphasizes  the  semantic 
distance  between  CCS  and  VHDL,  and  the  “pure”  CCS  translator  serves  as  a  more  telling 
example  of  how  hw  can  be  used  to  verify  a  translator,  which  is  shown  in  the  next  section. 
Following  that,  a  translator  targeting  the  broadcast  version  of  CCS,  which  is  semantically 
less  distant  from  VHDL,  will  be  introduced. 


5.5  Preservation  of  Congruent  Weak  Conformance 

Does  the  translator  outlined  in  the  previous  section  preserve  congruent  weak 
conformance?  That  is,  given  two  VHDL  design  units  E  and  F,  where  E  >-w  F,  can  one 
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say  that  [[£]]  hw  [[F]]?  The  question  is  interesting,  because  the  issue  oiVw  among  VHDL 
design  units  has  not  been  specifically  addressed  or  defined.  VHDL  modelers  do  not 
normally  think  of  design  units  as  being  compliant  to  one  another.  Rather,  a  design  unit  is 
considered  compliant  to  the  test  bench  that  exercises  it.  The  test  bench  is  little  more  than 
a  behavioral  model  that  provides  a  set  of  stimuli  and  checks  for  appropriate  responses. 
The  test  bench  thus  models  the  environment.  If  two  design  units  pass  the  same  test  bench 
then  they  are  considered  interchangeable  within  the  environment  modeled,  but  not 
necessarily  compliant  to  each  other. 

5.5.1  Congruent  Weak  Conformance  for  VHDL  Models.  For  the  purpose  of 
verifying  the  translator,  hw  between  VHDL  models  will  mean  the  same  as  it  does  for 
CCS  models,  i. e. ,  that  the  four  transitional  laws  and  the  five  construction  restrictions  are 
satisfied.  Therefore,  the  various  symbols  and  concepts  employed  must  have  meaning 
within  the  context  of  VHDL. 

Plainly,  VHDL  design  units  have  both  input  and  output  sorts.  They  are  given 
explicitly  in  the  entity  declaration.  From  these,  the  extraneous  input  and  output  sorts  can 
be  easily  determined. 

Furthermore,  translation  Rule  9  shows  that  VHDL  code  has  a  state  machine 
interpretation.  One  can  speak  of  labeled  transitions  such  as  E  — £— >■  when  the  possibility 
exists  that  the  next  simulated  transition  is  on  a. 

As  for  t  transitions,  VHDL  has  none.  Yet  the  various  internal  signals  of  a 
structural  VHDL  model,  though  hidden  at  the  top  level,  are  tracked  and  managed  by  the 
simulator.  Therefore,  one  can  assert  that  E — >  when  a  transition  on  one  of  these 
internal  signals  is  immediately  pending. 

The  notion  of  maxoctset  must  be  modified  somewhat  for  VHDL  models.  Since 
simultaneity  is  allowed,  VHDL  maxoctsets  may  include  paths  with  simultaneous  output 
transitions.  In  that  event,  the  implementation  is  permitted  to  either  duplicate  the 
simultaneity,  or  perform  the  actions  in  some  sequence.  Thus,  if  O  and  P  have 
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simultaneous  output  events,  then  the  derived  maxoctset  is  {O.P,  P.0,  O&P}  where  V  is 
borrowed  from  CCS  to  indicate  sequential  occurrence  and  where  ‘&’  denotes 
simultaneous  occurrence. 

5.5.2  Compliance  Example  Revisited.  Thus  hw  can  be  defined  over  VHDL  just  as 
it  was  for  CCS  agents.  To  illustrate,  return  to  the  BCD  decoder  example  of  Chapter  3. 
The  BCD  decoder  had  specification  S  had  two  implementations  /  and  J.  Possible  VHDL 
models  for  these  three  agents  appear  in  Appendix  D  in  the  level-signal  modeling  style. 

The  specification  model  S  begins  with  an  assertion  that  some  input  combinations 
are  illegal.  A  large  case  statement  then  responds  to  the  content  of  the  inputs  and  posts 
transactions  on  all  output  drivers.  Most  of  these  transactions  do  not  result  in  real 
transitions,  since  eight  of  the  outputs  will  retain  the  same  value  from  the  previous  state. 
Like  the  CCS  model  for  S,  only  two  of  the  outputs  will  experience  a  real  transition. 
Since  no  explicit  delay  is  specified,  both  transitions  occur  at  the  next  delta.  They  are 
simultaneous,  not  simply  concurrent.  Thus,  S  has  within  its  derivation  tree,  ten 
maxoctsets  of  the  form  {O.P,  P.O,  O&P}. 

Not  surprisingly,  implementation  /  resembles  S  except  for  the  addition  of  six 
outputs,  and  the  lack  of  an  assertion  that  bans  certain  input  combinations.  Once  again, 
no  delay  is  specified,  and  /  implements  the  maxoctsets  of  S  with  the  simultaneous  option 
of  the  form  O&P.  The  set  {OlO,  Oil,  012,  013,  014,  015}  constitutes  the  extraneous 
output  sort  !Ex}r(J,S),  and  transitions  at  these  additional  pins  are  tolerated.  These 

transitions  constitute  relative  taus,  but  produce  no  instability  since  they  are  guarded  by 
input  transitions. 

J ,  on  the  other  hand,  has  explicit  delays  associated  with  its  output  transactions. 
As  in  a  real  circuit,  these  delays  are  all  different,  and  true  simultaneity  will  not  occur. 
Thus,  for  each  maxoctset  of  S,  J  implements  one  of  the  sequential  options  and  never  the 
simultaneous  option. 
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One  can  apply  the  translation  rules  to  the  VHDL  models  for  S,  I  and  J.  Now  the 
VHDL  code  is  very  “busy”  in  that  it  posts  transactions  to  every  output  driver  upon  every 
change  of  input.  Most  of  these  transactions  do  not  survive  the  translation,  however. 
Since  Rule  9  mimics  the  VHDL  simulation  engine,  only  the  true  transitions  appear  in  the 
CCS  target  model.  Thus,  the  CCS  target  models  will  be  identical  to  the  models  given  in 
Chapter  3,  except  that  the  names  will  be  much  more  verbose.  The  agent  corresponding  to 
S  will  be  called  S_Behavior_Default  and  its  states  will  be  called  S_Behavior_Default_0, 
S  Behavior  Defaidt  l ,  and  so  forth.  The  action  labels  will  be  s_behavior_default_a, 
's _behavior  default _ol,  and  so  forth.  Manual  translations  of  the  S,  I  and  J  design  units 
appear  in  Appendix  E. 

In  passing,  it  must  be  stated  that  the  direct  production  of  a  CCS  pair  [[.S]]  [[/]] 

from  a  VHDL  pair  /  hw  S  is  an  ideal  that  will  be  imperfectly  realized.  CCS  supports  full 
encapsulation  of  specification  requirements  as  a  state  machine,  with  forbidden  sequences 
simply  omitted.  Models  are  directly  compared  for  conformance  in  a  manner  analogous  to 
equivalence  checking.  VHDL  must  use  asserts  to  prohibit  certain  sequences  and,  more 
likely,  specification  asserts  will  decorate  the  implementation  model  itself —  there  will  be 
no  separate  specification  model.  This  practice  resembles  the  model  checking  approach. 
Of  course,  VHDL  test  benches  are  models  that  do  check  specification  requirements,  but 
they  are  not  specification  models  in  the  same  sense,  just  simple  conduits  for  test  vectors. 
One  does  not  use  a  test  bench  as  a  placeholder  in  a  system  model,  to  be  replaced  by  an 
implementation  model.  So  the  presentation  of  two  VHDL  models  that  share  >-w  will  be 
rare. 

5.5.3  Proof  that  hw  is  Preserved.  One  is  now  assured  that  >-w  has  meaning  when 
applied  to  VHDL  models.  One  must  now  prove  that  whenever  E  hw  F  then  [[£]]  hw  [IT7]] 
necessarily  follows.  To  establish  this  implication,  one  must  prove  two  things:  (1)  that 
the  translation  rules  preserve  the  five  construction  laws  CS,  PEA,  ESP,  COR  and  BR,  and 
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(2)  that  the  translated  models  are  weakly  conformant,  i.e.,  [[£]]  Aw[[C]]  (single 
underline). 

Proposition  5-1.  The  translator’s  renaming  function  for  VHDL  design  units  and  signals 
(Rules  1,  3,  6  and  8)  is  an  injection. 

Proof.  Each  VHDL  design  unit  is  identified  with  a  unique  entity-architecture- 
configuration  triple.  This  unique  information  is  carried  forward  in  the  translation,  so  the 
renaming  of  VHDL  design  units  to  CCS  agents  is  injective.  Signal  names,  whether 
internal  or  external,  can  be  reused  by  different  design  units,  but  their  scope  is  limited  to 
that  design  unit.  The  VHDL  analyzer  must  maintain  such  scoping  information,  so,  in 
effect,  each  signal  has  a  design  unit  tag  that  insures  uniqueness.  The  <design  unit  name> 
prefix  added  in  Rules  3  and  6  maintains  that  uniqueness  in  the  target  models.  The 
renamed  open  port  assignment  of  Rule  8  is  unique  by  the  assumption  that  the  translator 
has  an  unlimited  supply  of  spare  names  to  secure  this  uniqueness.  □ 


Since  the  renaming  function  is  an  injection,  it  is  bijective  with  its  own  image. 
Therefore  one  can  speak  of  the  reverse  translation  [[V]]"1  of  CCS  agents  and  actions,  as 
long  as  the  reverse  translation  is  not  applied  to  the  additional  signals  (Rules  6  and  8)  and 
agents  (Rules  2,  5  and  9)  that  the  translation  generates. 

Proposition  5-2  establishes  that  actions  whose  order  of  occurrence  is  fixed  in  the 
VHDL  model  will  be  sequential  in  the  CCS  model.  Actions  whose  order  of  occurrence  is 
either  ambiguous  or  simultaneous  on  the  VHDL  side  is  concurrent  in  the  CCS  translation. 

Proposition  5-2.  The  translator  preserves  any  absolute  ordering  of  actions. 

Proof. 
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•  Rules  1  through  8.  These  rules  affect  only  the  assignment  of  names.  They  do  not 
redefine  sequence  of  actions. 

•  Rule  9.  As  a  faithful  mimic  of  the  VHDL  simulation  cycle,  the  state  machine 
extraction  algorithm  preserves  the  same  ordering  and  concurrency  of  events 
expressed  in  the  VHDL  code.  Simultaneous  events  become  ambiguously  ordered 
(i.e.,  concurrent),  but  any  event  occurring  strictly  before  or  after  a  simultaneity 
occurs  strictly  before  or  after  the  corresponding  concurrency  after  translation. 

•  Rule  (10).  There  are  two  cases  to  consider:  (1)  independence  (no  common 
inputs)  and  (2)  dependence  on  common  input  signals. 

Case  1.  Processes  and  components  that  share  no  common  inputs  can  proceed 
independently.  Thus,  they  are  concurrent.  Any  interleaving  of  the 
events  of  each  process  can  occur  that  is  consistent  with  the  behavior  of 
each  process  individually.  The  Parallel  Composition  in  the  target 
model  mirrors  that  concurrency. 

Case  2.  When  a  group  of  processes  and  components  share  common,  sensitive 
inputs,  they  progress  independently  except  at  points  where  they  await  a 
common  input.  After  receipt  of  that  input,  they  proceed  independently 
to  the  next  common  input.  CCS  cannot  activate  two  agents  at  the  same 
time  as  VHDL  does.  However,  insertion  of  the  FORK  agent  causes  the 
components  or  processes  to  wait  at  the  same  point  for  the  common 
sensitive  signal,  after  which  they  can  continue  independently. 

□ 


Proposition  5-3.  The  translation  rules  preserve  the  CS  assumption. 

Proof.  Since,  by  assumption,  CS  holds  for  the  pre -translated  VHDL  models — there  can 
be  no  unguarded  relative  taus  in  the  initial  models.  One  must  consider  whether,  as  a 
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result  of  translation,  (1)  guarded  relative  taus  can  move  to  unguarded  positions,  (2)  an 
unguarded  action  can  become  an  extraneous  output  action  by  renaming  and  (3)  the 
extraneous  action  created  by  Rule  8  can  become  unguarded. 

•  Case  1.  Proposition  5-2  guarantees  that  absolute  orderings  among  events  are 
preserved,  so  such  moves  are  not  possible. 

•  Case  2.  The  renaming  function  of  design  units  and  signals  is  injective  by 
Proposition  5-1,  so  the  membership  of  signals(actions)  in  the  sorts  of  design  units 
(agents)  does  not  change.  Hence  their  extraneous  or  non-extraneous  nature 
cannot  change. 

•  Case  3.  The  component  output  left  open  constitutes  a  hidden  action  in  the  VHDL 
model,  which  becomes  an  extraneous  output  upon  translation.  Again,  the  CS 
assumption  insures  that  the  VHDL  hidden  action  is  guarded;  and  Proposition  5-2 
prevents  the  resulting  extraneous  output  in  the  CCS  model  from  migrating  to  an 
unguarded  position. 

□ 


Proposition  5-4.  The  translator  preserves  the  PEA,  ESP  and  COR  conditions. 

Proof.  The  renaming  of  actions,  as  an  injection,  preserves  the  c:  and  e  relationships 
within  the  definitions  of  PEA,  ESP  and  COR.  □ 

Proposition  5-5.  The  translator  preserves  the  BR  condition. 

Proof.  All  relabelings  (port  maps)  on  the  VHDL  side  are  bijective  by  assumption.  The 
translator  renaming  function  is  bijective  to  its  own  image.  Hence  the  Relabelings 
resulting  from  translated  port  maps  are  bijective,  since  the  bijection  of  a  bijection  is 
bijective.  It  remains  to  show  that  Relabelings  introduced  by  the  Rule  10  preserve  BR. 
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These  functions  rename  process  and  component  inputs  to  communicate  with  the  branches 
of  the  introduced  FORKs.  Yet  these  branches  bear  new  and  unique  names  per  the 
naming  scheme  of  Rule  6,  so  BR  is  preserved.  □ 

Proposition  5-6.  The  translator  preserves  the  >-w  construction  laws. 

Proof.  Propositions  5-3,  5-4  and  5-5.  □ 


Having  shown  that  the  translator  preserves  the  construction  laws,  one  must  now 
establish  that  [[£]]  >-w  [[/-]].  This  can  be  shown  by  coinductive  proof  that  the  relation 
^  {([[£]],  [[*]]):£  ywF}  is  a  weak  confonnation  up  to  >-w.  First,  one  must  show  that 
the  translator  preserves  «  and  also  preserves  all  maxoctsets.  One  must  also  show  that  the 
reverse  translation  [[...]]',  when  it  exists,  preserves  these  properties. 

Proposition  5-7.  The  translator  and  its  inverse  preserve  observational  equivalence  «. 

Proof: 

•  Translator.  Show  that  5=  { ( [[P]],  [[Q\\  ) :  P  ~  Q  }  is  a  bisimulation  up  to  «. 

Whenever  [[P]]  =>  IT  then  P  =>  P'  where  [[at]]  =  a  and  [[P]]  =  R'. 

Since  P  «  Q  then  Q' «  P'. 

Hence  [[Q\\M\Q^  and  clearly,  ( [[P]],  [[0]]  )  e  S. 

•  Inverse  translator.  Define  S  =  {  (P,  Q) :  [[P]]  «  [[ Q\\  }.  The  proof  is  similar. 

□ 


Proposition  5-8.  The  translator  and  its  inverse  preserve  maxoctsets. 

Proof: 

•  Translator. 
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Let  M  be  a  maxoctset  of  F  converging  at  F'.  That  is,  Vm  e  M,  F=>  «  F'. 
Hence  V[[m]]  e  [[M]\,  [[/•]]  [=>  «  [[F]]  since  the  translator  preserves  «. 
Thus  [[M]]  is  at  least  an  octset  of  [[F]],  converging  on  [[F]]. 

Trial  Hypothesis.  Assume  [[M]]  is  not  a  maxoctset. 

Then  [[F]]  has  maxoctset  N  where 

N=  {[[m]\.n  :  m  e  M,  n  e  ^([[T]])+  and  [[F]]  ^S"}. 
Yet  if  [[F]]  => *5" then F'[S>'  »F" since  [[...]]'1  preserves  ». 
Hence  F^>  [S'  *  F"  V[[m]].n  e  A. 

Hence  [[A]]'1  is  an  octset  of  F  and  M  cannot  be  a  maxoctset. 

Thus  [[M\\  is  a  maxoctset  of  [[F]]  converging  at  [[F]]. 

•  Inverse  translator.  Similar. 


□ 


Proposition  5-9.  S=  {  ([[F]],  [[F]])  :  E  >-w  F  }  is  a  weak  conformation  up  to 

Proof: 

•  LSIT'.  Let  [[F]]^>A  Then  F^F'  where  [[a]]  =  a  and  [[F]]  =  S'. 

By  LSIT,  Ef>E'yw  F'. 

Since  absolute  order  among  actions  is  preserved  (Proposition  5-2),  then 
[[F]]  =>  [[F]]  where  u  =  [[/]]. 

Since  E'  F'  then  clearly,  [[F]]  S  [[F]]. 

•  LSO'.  Let  [[F]]  have  a  maxoctset  A  converging  at  S'. 

Then  F  has  maxoctset  [[A]]'1  converging  at  some  F\  where  F'  =  [[£"]]. 
F  implements  [[A]]'1  with  t: 

F=b>F'  F'  with  t  \  Jl(F)  =  n  e  A. 

Thus 
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[[£]]  i >[[£]],  [M]  UP1D  =  [W]  e  [[AG] 

and  clearly,  [[A1]]  5  [[f7]]. 

•  UI’.UOT.  Similar  to  LSIT’. 

□ 

Proposition  5-10.  Vw  is  preserved  by  the  translator. 

Proof:  Propositions  5-6  and  5-9.  □ 

Thus,  the  translator  defined  by  Rules  1  to  10  preserves  congruent  weak 
confonnance,  and  the  translator  is  validated. 

5.6  Translation  to  Broadcast  CCS 

The  translator  was  able  to  bridge  the  semantic  gap  between  VHDL  and  CCS 
while  preserving  hw  in  the  process.  Since  pure  CCS  does  not  support  multiple  fan-out, 
the  translator  had  to  insert  FORK  agents  into  the  target  code.  This  necessity  to  use 
FORKs  to  mimic  broadcast  communication  is  a  major  contributor  to  the  semantic  gap 
between  VHDL  and  CCS.  Furthennore,  the  resulting  target  code  is  very  limited  in  the 
types  of  verifications  it  can  support.  Using  FORKs  to  model  interconnect  corresponds  to 
the  delay-insensitive  asynchronous  design  model,  where  the  delay  associated  with 
interconnect  is  completely  unspecified.  Designs  verified  under  the  delay-insensitive 
assumption  are  very  robust,  but  achieving  a  working  design  under  delay-insensitive 
constraints  is  very  hard.  Only  a  very  limited  number  of  circuits  can  be  designed  using 
delay-insensitive  techniques. 

More  practical  asynchronous  designs  use  the  speed-independent  model. 
Interconnect  wiring  is  assumed  to  have  minuscule  delay  compared  to  the  delay  of 
components.  Thus  a  signal  propagates  essentially  simultaneously  along  the  branches  of 
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any  multiply  connected  node.  This  is  fairly  consistent  with  VHDL  modeling,  where  wire 
alone  has  no  delay,  though  inconsistent  with  pure  CCS  modeling. 

To  model  speed-independent  designs,  Stevens  added  transition  rules  to  CCS  for 
supporting  broadcast  communication  (Stevens,  1994:  180-5).  The  conjunction  operator, 
|c,  is  a  modification  of  Parallel  Composition,  and  allows  a  single  output  to  handshake  with 
more  than  one  input  action.  Five  transition  rules  give  the  semantics  of  |c.  Of  particular 
interest  is  Conj^ 


E\CF^E\F~ 


where  /  is  understood  to  be  an  output.  Compare  this  with  Milner’s  Com3: 

E-k-E  F-4-F 
Com,  - 

E I  F^El  F' 

'c  'c 

For  Milner’s  rule,  an  action/coaction  pair  collapses  to  r,  so  no  other  agents  can 
synchronize  on  it.  Stevens  rule  collapses  it  to  the  output  /  ,  ready  to  communicate  with 
additional  input  actions.  Thus,  a  single  output  can  drive  multiple  inputs,  thereby 
modeling  broadcast  communication. 

Though  Stevens  did  not  name  this  modified  CCS,  here  it  will  be  called  BCCS 
( Broadcast  CCS)  here  to  distinguish  it  from  Milner’s. 

A  VHDL-to-BCCS  translator  need  not  resort  to  the  insertion  of  FORKs.  Thus  the 
revised  translator  is  simpler.  Rules  6  and  10  are  modified  to  eliminate  the  insertion  of 
FORKs. 
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(6')  Locally  declared  signals  appearing  in  structural  models  are  internal  signals 
recognized  because  they  connect  to  component  ports.  Their  translation  is  to 
actions.  The  naming  convention  for  the  action  is 

local  action  name  ::=  <design  unit  name(lower  case)> _<vhdl  local  signal  name> 

A  local  action  can  connect  one  input  to  multiple  outputs  without  FORKs. 

(10’)  A  design  unit  is  translated  by  identifying  its  CCS  name  with  the  Conjunction  of 
its  contained  processes  and  components.  To  wit. 


<Design  Unit  Name>  = 

(  [[process^]]  ([[process?]]  |  ...  |  [[process*]] 

|  [[component;]]  |  [[component.?]]  |  ...  |  [[component,,,]] 

)\{  internal  signals  } 

Thus  the  VHDL-to-BCCS  translator  is  somewhat  simpler.  Does  this  translator 
also  preserve  hw? 

Proposition  5-11.  hw  is  preserved  by  the  VHDL-to-BCCS  translator. 

Proof:  Examine  Proposition  5-1  through  5-10  as  they  apply  to  the  new  translator. 
Proposition  5-1  still  holds  as  stated.  The  proof  of  5-2  is  simpler  since  it  is  uncomplicated 
by  FORKs.  The  proofs  of  the  remaining  propositions,  which  depend  on  5-1  and  5-2,  are 
unmodified,  so  the  VHDL-to-BCCS  preserves  hw  as  well.  □ 
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5. 7  Conclusion 


This  chapter  addressed  the  use  of  congruent  weak  confonnance  hw  to  verify  a  set 
of  transformations  from  one  modeling  language  to  another.  The  verification  of  such 
transfonnations  is  particularly  challenging  when  the  underlying  semantics  of  the  two 
languages  differ.  Loss  of  information  is  inevitable  in  such  translation.  However  hw, 
which  models  the  designer’s  desire  for  safe  substitution,  needs  to  be  preserved  in  the 
course  of  a  useful  translation. 

In  this  chapter,  VHDL-to-CCS  translation  was  examined  under  the  light  of  >-w. 
First,  the  various  semantic  differences  between  VHDL  and  CCS  were  duly  noted.  Next, 
some  small,  but  interesting  agent  models  were  presented  to  elucidate  those  differences 
and  to  serve  as  a  basis  for  further  study  of  the  translation  process.  These  models  were 
selected  to  exhibit  the  salient  feature  of  hw  by  incorporating  examples  of  extraneous 
actions,  hidden  actions,  and  maxoctsets. 

The  models  were  presented  in  three  groups.  First,  the  reference  models  served 
simply  to  present  the  behavior  under  discussion.  Though  given  in  CCS,  the  reference 
models  were  not  intended  to  be  translated  or  to  be  the  result  of  translation.  Instead,  the 
true  objects  of  translation  were  the  initial  models,  given  in  VHDL.  The  initial  models 
were  inspired  by,  but  not  formally  derived  from,  the  reference  models.  The  target 
models,  however,  were  CCS  models  mechanically  derived  from  the  initial  models  by  a 
hypothetical  translator. 

The  translator  consisted  of  ten  rules.  The  most  important  rule  mapped  the  VHDL 
process  construct  to  a  CCS  agent.  Parallel  Composition  then  combined  agents  that 
represented  parallel-acting  processes  and  components  in  the  VHDL  models.  Other  rules 
defined  the  assignment  of  agent  and  action  names  upon  translation.  In  section  5.4,  the 
translator  was  then  shown  to  preserve  hw  during  the  course  of  translation.  Thus,  the 
translator  preserved  safe  substitution,  and  therefore  the  translator  was  verified. 
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A  second  translator  that  targeted  the  more  practical  Broadcast  CCS  was  also 
discussed.  Since  Broadcast  CCS  has  a  communication  semantics  closer  to  VHDL,  the 
second  translator  is  less  complex.  This  translator  was  also  verified  by  proof  that  it 
preserves  hw. 

In  summary,  this  chapter  demonstrated  the  use  of  >-w  to  verify  transfonnations 
between  systems  of  unlike  semantics.  Language  translators  are  but  one  example  of  such 
transfonnations.  Synthesis  and  extraction  tools  such  as  those  used  in  integrated  circuit 
design  are  also  transfonnation  systems,  and  should  be  amenable  to  verification  by  >-w. 


5-43 


VI.  Conclusion 


This  chapter  summarizes  the  dissertation,  lists  the  original  contributions  of  the 
present  research,  and  provides  recommendations  for  future  research. 

6.1  Summary 

This  dissertation  started  with  intuitive,  informal  notions  of  compliance.  In  the 
end,  a  property  called  congruent  weak  conformance  that  captured  these  intuitive  notions 
was  defined,  formally  developed,  and  used  to  verify  translations  between  incompatible 
semantic  systems. 

Chapter  1  gave  a  brief  introduction  to  the  problem  of  compliance,  and  ended  with 
a  diagram  (Figure  1-1)  showing  that  the  desired  property  is  probably  not  an  equivalence. 

Chapter  2  presented  the  prior  art.  In  particular,  Chapter  2  presented  various 
formal  equivalences  that  have  been  defined  over  the  process  algebra  CCS.  However, 
since  a  confonning  implementation  can  exhibit  behaviors  in  excess  of  its  specification, 
equivalences  were  seen  to  be  insufficient  to  the  task.  Therefore,  various  process-ordering 
relations  from  the  literature  were  also  presented,  with  their  shortcoming  noted  as  well. 

To  extract  all  the  intuitive  aspects  of  conformance,  Chapter  3  provided  a  simple 
example  of  a  specification  (a  BCD  converter)  and  a  conforming  implementation  (an 
appropriately  wired  demultiplexor).  The  intuition  gained  from  the  example  was  then 
formalized  into  four  transition  rules.  These  rules  defined  a  family  of  relations  called 
weak  conformations .  Some  formal  results  were  proven  for  weak  conformations. 
However,  the  weak  confonnations  were  only  precursor  relations,  and  needed  refinement 
to  produce  the  ultimate  desired  property. 

These  refinements  were  presented  in  Chapter  4.  The  first  refinement,  weak 
conformance  (>-w),  was  presented  as  the  largest  of  the  weak  confonnations.  Formal 


6-1 


results  governing  !>>  were  proven,  and  the  property  held  promise.  Yet  it  was  not  possible 
to  show  that  >>  is  fully  substitutable,  i.e.  it  is  not  a  congruence.  Hence,  additional 
refinement  was  needed.  This  refinement  consisted  of  five  constructional  restrictions  that 
govern  the  building  of  specification  and  implementation  models.  These  restrictions  were 
shown  to  be  very  reasonable  constraints  that  do  nothing  more  than  codify  good  design 
intent.  Congruent  weak  conformance  hw  was  then  defined  as  >w  with  the  additional 
refinement  that  the  five  design  restrictions  must  be  observed.  Congruent  weak 
confonnance  was  then  proven  to  be  a  congruent  partial  order,  or  precongruence.  This 
established  hw  as  the  final  desired  property:  the  loosest  known  model  of  conformance 
that  provides  for  safe  substitution. 

To  apply  hw  to  a  practical  problem,  Chapter  5  investigated  a  hypothetical  VHDL- 
to-CCS  translator.  This  type  of  translator  is  challenging  to  build  because  the  VHDL  and 
CCS  semantics  are  incompatible,  and  information  must  necessarily  be  lost  in  the  course 
of  the  translation.  For  verifications  upon  translated  models  to  be  valid,  some  appropriate 
property  must  be  preserved  by  the  translator.  Since  the  designer’s  art  can  be 
characterized  as  the  search  for  an  implementation  to  substitute  for  a  specification,  then 
safe  substitution  {i.e.  >-w)  is  the  property  that  must  be  preserved. 

The  hypothetical  translator  was  summarized  as  a  set  of  ten  transformations.  Each 
transfonnation  was  then  shown  to  preserve  hw.  This  in  effect  verified  the  VHDL-to-CCS 
translator.  A  translator  from  VHDL  to  a  more  practical  Broadcast  CCS  was  also 
verified. 

The  objects  of  this  research  were  five-fold: 

1.  Detennine  the  characteristics  of  a  compliant  device  with  respect  to  its 
specification.  Study  the  expected  behavior  of  an  implementation  in  response  to 
specified  input,  output  and  hidden  action.  Conversely,  note  any  reverse 
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obligations  of  the  specification  to  implemented  input,  output  and  hidden 
action. 

2.  Incorporate  this  intuition  into  the  formally  defined  property  of  congruent  weak 
conformance  as  a  binary  relation  over  processes.  Make  this  formal  property  as 
“loose”  as  possible  such  that  it  admits  all  appropriate  implementations  and 
allows  maximum  design  flexibility. 

3.  Derive  fonnal  results  for  congruent  weak  confonnance  and  related  properties. 
Prove  that  congruent  weak  conformance  is  partial  order.  Prove  also  that 
congruent  weak  confonnance  is  fully  substitutable  in  all  contexts,  is  a  valid 
model  of  safe  substitution,  and  is  indeed  a  congruence. 

4.  Outline  the  transformations  necessary  to  create  a  semantic  link  from  VHDL  to 
CCS. 

5.  Show  that  such  transfonnations  are  valid  by  proof  that  they  preserve 
congruent  weak  conformance,  thus  allowing  the  more  powerful  verifications 
of  CCS  to  accrue  to  VHDL  models. 

These  objects  have  been  accomplished. 

6.2  Contributions 

This  research  has  yielded  several  original  contributions:  (1)  local  confluence, 
(2)  the  concept  of  a  maxoctset,  (3)  the  transitional  laws  that  define  the  weak 
conformations,  (4)  relative  stability,  (5)  the  five  model-construction  restrictions,  (6)  the 
relation  >-w,  and  (7)  a  methodology  for  verifying  transformations  between  systems  of 
unlike  semantics. 

6.2.1  Local  confluence.  Local  confluence  is  a  looser  notion  than  the  classical 
confluence.  Local  confluence  identifies  areas  of  a  transition  graph  that  exhibit  confluent- 
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like  behavior  in  the  absence  of  a  global  confluence.  With  local  confluence,  one  can 
identify  and  exploit  behavioral  options  offered  by  a  specification  model. 

6.2.2  Maxoctsets.  The  maxoctset  denotes  local  confluence  among  outputs  and 
hence  represents  output  options  offered  by  the  specification.  Maxoctsets  are  the  largest 
such  areas  that  can  be  identified.  Being  the  largest,  they  represent  the  least  restriction 
possible  restriction  on  the  designer  in  implementing  specified  output  actions. 

6.2.3  Weak  conformations.  Four  transitional  laws  characterize  the  weak 
conformations.  These  laws  provide  the  greatest  flexibility  in  implementation  by 

(1)  abstracting  hidden  action  in  a  manner  similar  to  weak  bisimulation. 

(2)  allowing  the  implementation  to  engage  in  unspecified  behavior  in  the 
unreachable  state  space  in  a  manner  similar  to  logic  confonnance, 

(3)  providing  for  additional  I/O  pins  in  the  implementation  that  do  not  block 
specified  behavior, 

(4)  allowing  maximum  exploitation  of  output  concurrency  through  the  use  of 
maxoctsets 

As  the  largest  weak  conformation,  weak  conformance,  >>,  unites  every  pair  of 
process  agents  that  share  the  transitional  laws. 

6.2.4  Relative  stability.  The  notion  of  stability  has  been  generalized  to  relative 
stability  in  recognition  that  unguarded  extraneous  outputs  can  play  the  same  destabilizing 
role  as  unguarded  taus  in  creating  unstable  models. 

6.2.5  Model  construction  restrictions.  Five  design  restrictions  pertinent  to  the 
construction  of  models  have  been  identified.  These  restrictions  are  an  embodiment  of 
consistent  design  intent.  Adherence  to  these  restrictions  is  a  prerequisite  to  achieving 
safe  substitution. 

6.2.6  Congruent  weak  conformance.  The  congruent  weak  conformance  property 
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hw  is  the  final  process  relation  derived  in  this  research.  As  a  refinement  of  >-w,  it  enjoys 
the  design  flexibility  of  the  weak  confonnations.  By  incorporating  the  five  model 
construction  restrictions,  it  also  models  safe  substitution  .  Hence,  hw  is  a  congruence, 
and  this  has  been  shown  by  extensive  proof. 

6.2.7  Transformation  verification  methodology.  If  translation  or  other 
transformations  between  systems  with  incompatible  semantics  is  attempted,  then  safe 
substitution  (i.e.  congruence)  must  be  preserved,  even  when  other  information  is  lost.  As 
the  loosest  known  precongruence,  hw  thus  fonns  a  useful  tool  to  verify  such 
transfonnations.  Such  usage  has  been  illustrated  by  the  verification  of  two  hypothetical 
VHDL-to-CCS  translators. 

6.3  Recommendations  for  Future  Work 

More  work  can  always  be  done.  In  the  course  of  the  present  research,  several 
interesting  topics  became  manifest  as  possible  follow-on  efforts.  These  topics  are: 

(1)  Axiomatization  of  >-w. 

(2)  Automated  hw  tool. 

(3)  Implemented  VHDL-to-CCS  translator. 

(4)  Verification  of  translators. 

(5)  Verification  of  synthesis  tools. 

6.3.1  Axiomatization  of  yw.  Congruent  weak  conformance  was  defined  in  terms 
of  four  transitional  laws  and  five  design  restrictions.  Thus,  to  prove  that  A  >-w  B  one  must 
ultimately  show  that  A  and  B  satisfy  these  laws  and  restrictions.  An  alternate 
formalization  of  hw  by  means  of  axioms  may  be  possible.  A  few  primitive  pairs  of  agents 
would  be  assumed  to  observe  hw,  and  this  would  yield  a  set  of  axioms.  The  proof  that 
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A  w  B  would  then  be  a  theorem  to  be  derived  from  the  axioms.  Observational 
equivalence  =  was  axiomatized  in  this  way  (Milner,  1989:160-9). 

6.3.2  Automated  >-w  tool.  For  the  present  research  it  sufficed  to  use  >-w  as  a 
manual  proof  tool  to  verify  transformations.  For  any  two  agents  A  and  B ,  whether  or  not 
A  hw  B  must  be  proven  manually  at  the  present  time.  However,  an  automated  tool  to 
establish  >-w  between  two  agents  would  be  a  great  aid  to  designers  and  logisticians. 
Furthermore,  if  an  axiomatization  of  hw  is  achieved,  then  an  extant  automated  theorem 
proving  tool  could  be  used  in  this  role. 

Guidance  for  producing  an  automated  hw  tool  is  now  offered.  This  tool  must 
determine  two  things:  (1)  that  a  weak  confonnation  exists  between  two  agents  and  (2) 
that  the  five  construction  restrictions  are  obeyed.  Both  tasks  require  knowledge  of  the 
extraneous  sorts,  with  (2)  requiring  a  more  detailed  knowledge  of  the  extraneous  sorts  of 
any  component  agents  down  to  the  purely  behavioral  level.  Thus  the  Aw  tool  will  likely 
accomplish  the  following  tasks: 

(1)  Extract  the  input  and  output  sorts  of  each  agent  as  well  as  the  sorts  for  each 
component  agent.  As  a  compromise,  the  tool  will  extract  syntactic  sorts  only, 
since  the  determination  of  semantic  sorts  is  undecidable.  Having  settled  on 
syntactic  sorts  only,  a  straightforward  lexical  analysis  of  agent  expressions 
will  then  suffice  to  accomplish  this  task. 

(2)  Calculate  the  extraneous  sorts  of  each  agent  and  any  component  agents. 
These  extraneous  sorts  will  be  easily  derived  by  set  difference. 

(3)  Check  for  violations  of  the  five  construction  laws.  The  analysis  will  halt  and 
report  if  any  such  violation  is  found. 
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(4)  Use  an  appropriate  algorithm  to  determine  if  a  weak  conformation  exists. 
Such  an  algorithm  has  not  yet  been  invented.  No  doubt  it  will  be  similar  to 
existing  algorithms  that  are  used  to  detennine  the  existence  of  a  bisimulation 
between  agents  (Cleaveland,  1989;  Fernandez,  1989;  Stevens  1994,  194-195). 
However,  any  weak  confonnation  algorithm  will  probably  be  more  complex 
than  any  of  the  bisimulation  algorithms,  owing  to  the  greater  complexity  of 
the  weak  conformation  laws  over  bisimulation  laws. 

Once  the  hw  tool  is  built,  test  cases  will  then  be  needed  to  validate  the  tool. 
Obviously,  both  behavioral  and  structural  agent  pairs  that  are  known  to  share  the  hw 
relation  will  need  to  be  submitted  as  validation  tests.  Equally  important,  though,  are 
pairs  that  are  expected  to  fail  >-w.  Failure  cases  must  be  constructed  to  contain  violations 
of  each  of  the  five  construction  restrictions.  In  addition,  tests  that  challenge  each  aspect 
of  the  conformation  laws  need  to  be  constructed.  Examples  of  failure  cases  that  should 
appear  in  any  validation  suite  include: 

(1)  interleaving  inputs  {specified  as  well  as  extraneous  inputs)  that  take  the 
implementation  to  illegal  behavior. 

(2)  interleaving  outputs  (specified  and  extraneous)  that  take  the  implementation  to 
illegal  behavior. 

(3)  maxoctsets  illegally  implemented.  For  example,  the  implementing  string  may 
contain  the  proper  output  actions,  but  in  an  order  that  is  unspecified,  i.e.,  that 
order  of  actions  is  missing  from  the  maxoctset. 

(4)  specifications  having  actions  extraneous  to  the  implementation.  These  should 
result  in  immediate  violation  of  LSIT  and  LSO. 

(5)  implementations  that  lead  to  illegal  behaviors  triggered  by  an  input  action  — > , 
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when  the  specification  can  or  cannot  perfonn  an  immediate  => . 

(6)  agent  pairs  that  are  not  relatively  stable. 

(7)  constructions  that  promote  extraneous  actions  to  specified  actions,  using 
Prefix,  Choice  and  Parallel  Composition. 

(8)  constructions  that  attempt  to  synchronize  on  extraneous  actions. 

(9)  relabeling  functions  that  are  not  bijective. 

(10)  non-idle  extraneous  outputs  illegally  restricted. 

These  above  guidelines  will  hopefully  aid  the  production  and  testing  of  a  future 
congruent  weak  conformance  checking  tool. 

6.3.3  Implemented  VHDL-to-CCS  translator.  Chapter  5  provides  the  outline  of  a 
VHDL-to-CCS  translator.  The  obvious  next  step  is  to  build  and  verily  such  a  translator. 
Such  a  translator  would  allow  the  bisimulation-based  verifications  possible  within  CCS 
to  accrue  to  VHDL  models.  Hence  such  a  translator  would  be  a  good  design  aid. 

Guidance  for  producing  such  a  translator  has  been  given  already,  since  an  explicit 
listing  of  the  translation  rules  is  given  in  Chapter  5.  The  most  difficult  rule  to  realize  will 
be  the  state  machine  extraction  algorithm.  Yet  that  algorithm  mimics  the  VHDL 
simulation  cycle,  and  implemented  VHDL  simulators  abound.  Thus,  a  likely  way  to 
implement  the  translator  may  be  by  modification  of  existing  VHDL  analyzers  and 
simulators,  with  a  new  “back-end”  targeted  to  output  CCS  state  machines  in  place  of  an 
explicit  event-based  simulation. 

6.3.4  Verification  of  translators.  Similarly,  other  existing  translators,  as  well  as 
newly  introduced  translators,  could  and  should  be  verified  using  hw.  The  bigger  the 
semantic  gap  between  the  initial  language  and  its  target,  the  more  useful  such  a 
verification  could  be. 


6-8 


6.3.5  Verification  of  synthesis  tools.  In  the  design  world,  transformational 
systems  abound.  Though  one  does  not  think  of  them  as  translators,  the  class  of  computer- 
aided  design  tools  called  synthesis  tools  are,  in  fact,  transfonnational  systems.  They 
perform  transformations  between  design  language  models,  schematics,  netlists  and  even 
silicon  layout.  There  is  often  a  semantic  gap  involved  in  synthesis.  For  example,  logic 
that  can  be  expressed  in  a  language  model  may  not  have  an  exact  equivalent  within  the 
component  library  of  a  particular  technology,  and  a  component  of  different  functionality 
may  be  substituted.  Furthermore,  once  an  actual  layout  is  generated,  certain  physical 
parameters  (resistance,  delay  time,  etc.)  become  instantiated,  and  these  may  have  an 
effect  on  the  desired  functionality.  These  parameters  often  have  to  be  “back-annotated” 
into  the  original  model  so  the  functionality  can  be  rechecked.  Thus,  synthesis  is  an 
example  of  inter-semantic  translation.  There  is  a  change  or  loss  of  information  in  the 
process.  Again,  safe  substitution  must  be  preserved.  This  suggests  that  hw  be  used  to 
verify  such  synthesis  tools. 

6.4  Concluding  Remarks 

The  objects  of  this  research  were  met.  Intuitive  notions  of  confonnance  were 
captured  formally.  The  resulting  property,  congruent  weak  conformance,  was  then 
shown  to  be  a  congruence,  and  therefore  a  correct  model  of  safe  substitution.  Congruent 
weak  confonnance  was  then  successfully  used  to  verify  transfonnations  between  systems 
of  unlike  semantics.  Thus  congruent  weak  conformance  was  shown  to  be  a  useful 
verification  tool. 


6-9 


Appendix  A 


Strong  Conformation 

For  strong  conformations,  z  is  treated  as  an  output.  The  implementation  must 
match  explicit  z  actions  in  the  specification,  though  it  is  free  to  add  more  of  its  own. 
Specified  r  actions  are  treated  like  outputs  since,  like  outputs,  the  environment  cannot 
control  their  emission.  The  maxoctset  concept  must  be  modified  to  include  z  actions 
amidst  the  outputs.  Call  this  a  maxtoctset  (with  an  extra  ‘t’  for  ‘tau’).  LSO  becomes 
“LSOT”  and  LSIT,  which  loses  its  rrole,  becomes  “LSI.”  LII  and  LIOT  are  unmodified. 

For  LSOT,  the  implementation  selects  some  string  s  from  the  maxtoctset,  where  s 
consists  of  both  outputs  and  z  actions.  This  sequence  of  outputs  and  taus  must  be 
faithfully  implemented,  and  the  specified  z  actions  cannot  be  deleted  in  the 
implementation,  though  additional  z  actions  and  extraneous  outputs,  may  be  added. 
t\  J  (S)  =  s  no  longer  captures  the  desired  relationship  between  t  and  5,  since  5  has 
embedded  taus.  t\{A  (S)  u  {r})  =  5  does  not  work  either,  due  to  the  extra  taus  that  t 
may  add.  Therefore  5  has  to  be  expressed  as  j30./3i..../3n  where  the  f,  range  over  output 
and  r. 

Definition  A-l.  A  binary  relation  on  processes,  S  c:  <P  x  (p,  is  a  strong  conformation  if 
Va  e  JL(S),  V J3  e  jl  (/)  u  {  z),  Vy  e  JL(S) ,  I S S  implies  the  following  four  laws: 

Law  of  Specified  Input  (LSI) 

Whenever  S'  then  3 1  e  (A(S)  u  ‘Extr  ( I,S ))*  such  that 

(1)  /  A  /' 

(2)  t  \  J(S)  =  a 

(3)  FSS' 
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Law  of  Specified  Output  or  Tau  (LSOT) 

Let  X  be  a  maxtoctsct  of  &  3  s  =  J30.j3i....j3n  eX  (where/?;  e  JL(S)  u  {  z})  and 
3 1  e  (J4(l)yj  {  z)  f  such  that 

(1)  S-b>S’ 

(2)  /  =>/' 

(3)  /  i  J (5)  u  { z)  =  z.fh-  z* . z*.j3n.  z* 

(4)  /'  <WS’ 

Law  of  Implemented  Input  (LII) 

Whenever  I  A- 1'  and  S  then 

(1)  SAS' 

(2)  I' S  S' 

Law  of  Implemented  Output  or  Tau  (LIOT) 

Whenever  1  AT  and  8  =  j3t  J  (S)  then 

(1)  S  *>S' 

(2)  I’SS' 
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Appendix  B. 


Lengthy  proofs 


Proof  of  Proposition  3-9. 

For  P  VQ  MR  let  R  M  R'  for  a  e  A(R)  u  {  z). 

•  Applying  LSIT  on  Q  M  R  yields  some  5  e  (MR)  u  Extr  ( Q,R ))*  such  that 

Q^QL  S\A(R)=  a,  Q'  MR'. 

•  Rewrite  Q=>Q'  as  Qf>  QiM  Qj  =>  Q'  where  u,  v  e  Extr  ( Q,R )*  and  any  r  actions  in 
=>  are  subsumed  by  =>  and  => .  ( M  represents  the  empty  transition  -M  for  a  =  z.) 

•  There  are  two  cases  for  string  u:  (1)  u  =  s  and  (2)  u  ^  s. 

Case  1.  P^P,  VQi  by  LSE. 

Case  2.  u  is  a  specified  output  to  be  implemented  by  P  under  LSO. 

:.3r  e  A  ( P)+  such  that 

P=>Pi,  r\  A(Q)=  confW,  Pi  VQj. 

•  Since  Pi  VQi  and  Qi  M  Q2  there  are  two  cases  for  a:  (1 )  s  and  (2)  a  =  er. 

Case  1.  Apply  LSO.  3  x  e  [A(Q)  u  ‘Extr  (P,Q)f  such  that 
Pi=>Pj,  x  \ A(Q)  =  a,  Pj  V Qi. 

Case  2.  Apply  LSE. 

Pi  =>  P2,  Qi  =>  Q2,  Pi  V  Q2. 

•  Performing  the  same  case  analysis  on  v  that  was  done  on  u  yields: 

P2=>P'  VQ'  for  some y  e  A(P)*  where y  \  A(Q)  =Conf  v. 

•  .'.  P  =>P'  where  t  =  r.x.y  and  P'  VWR'. 


B-l 


It  remains  to  be  shown  that  t  \  MR)  =  a  . 

•  Both  r  and  v  are  composed  of  output  strings.  Their  projections  onto  input  sort  MR) 
are  empty. 

•  :.t\  MR)  =  r.x.y  \  MR)  =  x  i  MR). 

•  By  LSIT  on  Pj  V  Qi  one  knows  thatx  i  MQ)  =  «  • 

•  Since  MR)  <=  MQ)  then  x  i  MR)  =  x  i  MQ)  i  MR)  =  &  \  MR)  =  &  ■ 

□ 

Proof  of  Lemma  4-12. 

First  show  that  every  maxoctset  of  (S  \  T)  can  be  represented  with  respect  to  some  Sj.tj. 
Then  show  that  every  such  s,.  tj  defines  a  maxoctset  o  f  (.S'  7j. 

•  Let  M  be  a  maxoctset  of  (S  \  T)  with  respect  to  r. 

•  Write  r  =conf  s.t  where  5  and  t  are  the  actions  provided  to  r  by  S  and  T,  respectively, 
with  the  symbols  appearing  in  r  in  the  same  order  they  appear  in  s  and  t,  though  they 
are  intermixed  in  r. 

•  Thus  S',  TM  T  and  (S\T)±>  (S' \  V). 

•  By  definition,  Vr;  e  M,  (S  \  T)  =>  «  (S'  \  Tj. 

•  Similar  to  r,  let  r,  =conr  st.  t,  such  that  S  =>  «  S'  and  T  b>  ~  T'. 

•  Note  that  st  =conf  5  and  t,  =conf  t. 

•  .’.  5  defines  an  octset  for  S,  as  does  t  for  T. 

•  Trial  Hypothesis .  Assume  one  of  these  octsets  is  not  a  maxoctset.  W.l.o.g.  let  it  be 
the  octset  of  S  defined  by  5. 

•  Then  S  must  then  have  a  maxoctset  MQ  with  respect  to  s.s"  for  some  s'M  s. 

•  Vs'  eMs':S  ^>«S". 

•  Vr'  =confS.s".t  where  ( S  \  7)^>  one  has  ( S  \  T)  L>«  (S"  \  Tj. 
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.'.  {r’  =COnf  s.s".t :  (S  |  T)  }  is  an  octset  of  (S  \  T)  and  M cannot  be  a  maxoctset. 


Now  show  that  every  such  s,.tj  defines  a  maxoctset  of  (S\ T). 

•  Let  My  =  {  r  :  (S  \  T)  and  r  =conf  st.  /,  } . 

•  Vjc  e  My  write  x  =conr  s.t  for  some  5  e  Yh  t  e  Z,. 

•  Since  7,  and  Z,  are  maxoctsets  one  derives  that  Vs  :  S  =>  «  S'  and  Vt :  T=b  ~T'. 

•  Vx  e  My  :  (S  \  T)  =>  «  (S'  \  T1)  and  hence  My  is  (at  least)  an  octset  of  ( S  \  T). 

•  Trial  Hypothesis.  Assume  that  My  is  not  a  maxoctset  of  fS  T). 

•  Then  (S  \  T)  has  some  maxoctset  with  respect  to  s{tj.x'  where  x'  ^  s. 

•  Let  x'  =COnf  s'.t'  where  s',  t'  are  the  contributions  to  x\  in  sequence,  from  S  and  T. 

•  At  least  one  of  s',  t'  *  s.  W.l.o.g.  let  s'  ^  s. 

•  Vr  =COnf  Si- s'  such  that  S  => ,  one  has  S".  S  has  an  octset  with  respect  to  s,.s '. 

•  Y,  cannot  be  a  maxoctset  of  S. 


Proof  of  Proposition  4-13. 

Given  /  W  S  and  J  W  T,  construct  the  relation 

{{I\J),{S\T)):I‘WS,J‘WT} 
and  show  that  S  is  a  weak  confonnation. 

•  LSIT.  Let  (  S  |  T)  where  a  e  A(  S  \  T).  There  are  two  cases  to  consider: 

(1)  a  is  a  visible  action  or  an  explicit  remitted  by  one  of  the  two  agents. 

(2)  a  is  a  r  arising  from  communication  between  the  two  agents. 

Case  1.  Assume  w.l.o.g.  that  S  -^>5".  Apply  LSIT  on  /  WS  yielding: 


/=>  /' 
t  \  A(S)  =  a 
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/'  WS'. 

Hence,  whenever  (  S  T )  ( S'  \  T)  then 

(/  \J)±(I'\J) 

Furthermore, 

t  \  A(S\T)  =  d 

by  an  argument  analogous  to  Proposition  4-11  (LSIT). 

Finally, 

(I'\J)  S  (S'  \T) 
since  /'  V2S’  and  J  <WT. 

Case  2.  Assume  w.l.o.g.  that  S  S'  and  T  where  a  is  an  input  and  a  an  output. 

(Note  that  a  is  a  participant  in  some  maxoctset  of  S  and,  though  it  appears  first  in 
some  member  string  of  that  maxoctset,  it  may  not  appear  first  in  the  member  string 
that  is  implemented  by  J.) 

First  apply  LSO  to  J  WT: 

T  =b>  =>  F 

Jh  ^>J' 

til  A(T)  =  Si,  t2  t  A  (T)  =  s2 
J'WT'. 

Then  apply  LSIT  to  I  WS: 

S^S' 

rj  l JL(S)  =  £,  a\ JL(S)  =  a,  rt  \ JZ(S)  =  £ 

/'  <WS\ 

Combining  the  results  of  LSO  and  LSIT  under  Parallel  Composition: 

(S  |  T)  (S'  |  T)  \ 

(7|  J)%  \ 
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where  m  =COnf  rj.ti  and  u2  =conf  r2.t2. 

Now  ri,  r2  e  ‘Eytr  (S)  and  .'.by  PEA,  ri,  r2  e  ‘Eytr  ((S  |  7))  as  well. 

PEA  also  prevents  the  promotion  of  extraneous  outputs  in  tj  and  t2.  Hence 
ti\A(S  |  T)  =  t1\J(T)  =  s1 
t2  \  A  (S  |  T)  =  s2. 

Thus, 

ui.ra.u2  \  A((S  |  T))  =  sj.s2 
snd  clearly 

(/'  |  J')  5  (S'  |  n. 

•  ISO. 

Let  M  be  a  maxoctset  of  (S  \  T). 

By  Lemma  4-12,  Bmaxoctsets  Y of  S  and  Z  of  T  such  that 

M  is  a  maxoctset  with  respect  to  y.z  for  some  y  e  Y,  and  z  e  Zj. 

By  LSO,  3s  e  Y  such  that 

S^>S\  I  =>/',  u  1  A  (S)  =  s,  I’  <WS’. 

Similarly,  3t  e  Zsuch  that 

r=>r,  j^>  j\  v\Jl(T)  =  v,  f  <wr. 

:.  (S\T)  ±>(S'\T)  ±>  (5' |  T)  and  similarly,  (7|  J)  A>  ^  (7'|  J'). 

Since  (  S  \  T)  =b>  and  5./  =COnf  v.z  then  s.t  &  M. 

PEA  guarantees  that  no  extraneous  outputs  in  u  or  v  are  promoted. 

u\  A  ((  S  |  T ))  =  u  \  A(S)  =  s  and  similarly,  v  1  A  ((  S  \  T  ))  =  t. 

Hence  u.v  \  A((S\  T))  =  s.t. 

Clearly  (I'\J')S  (  S' \  T '). 

:.  u.v  is  a  valid  implementation  by  ( 7 1  J)  of  s.t  e  M. 

•  III. 

Let  ( 7 1  J)  -A  for  /e  A((  S  T )).  W.l.o.g.  assume  7  -A/'. 

LII  requires  that: 
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5  4  5',  /'  WS'. 

Thus:  (S\T)  4( S'\T ), 

(I\J)  -4(7' |  J)and 
(7'|  J)5(S'  |  T). 

•  LIOT. 

Let  ( / 1  J  )  -4  i3'  where  /?  e  yl(/|/)u{r}.  There  are  two  cases  to  consider: 

(1)  p  is  an  output  or  explicit  remitted  by  one  of  the  components. 

(2)  p  is  a  r  arising  from  communication  between  the  components. 

Case  1.  W.l.o.g.  let  /  4  /'.  Thus  P’  =  (/'  |  J) 

By  LIOT  on  I  %’S  one  has 

Si>S’,  d=p\  J(S),  I'WS'. 

If  p  £  A(S)  then  P  £  A  (  S  \  T))  by  the  PEA  condition. 

:.8  =p\  J(S)  =  p\  J(S\T). 

Hence  one  has: 

(i\j)Mr\J) 

(S\T)  i>  (S'\T) 
p\  A((S\T))  =  8 
(I'\J)  S  (S'  j  T). 

Case  2.  W.l.o.g.  let  /  -4/'  and  J4J',  where  a  is  the  input  action. 

(I\J)  4  ( /'  |  /')  and  thus  P'=  ( I'\J '). 

There  are  two  cases  on  a.  All  other  cases  violate  ESP. 

(a)  a  €  A(S)  and  a  e  A(T). 

(b)  a  e  (Extr(I,S)  and  a  e  cExtr(J,T). 

Case  a.  First,  apply  LIOT  to  J  rWT\ 

T  4  r,  8=  a  \  J(T)  =  a,  J'  <WT'. 

Now  apply  LII  to  I  %CS\ 

S  =>S\  (S\  T)  =>  (S'\ T').  ( I’\J’)S  ( S'\T '). 
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Case  b.  Both  signals  are  extraneous  to  their  respective  specifications. 


S  S',  T^T',  (S  \T)  (S'\T'). 

Again ,(I'\J')S  ( S'\T '). 

□ 


Proof  of  Proposition  4-14. 

It  suffices  to  conduct  the  proof  for  a  singleton  Restriction  set  {c}.  All  others  will  yield 
to  induction. 

•  Let  I  WS  for  some  weak  confonnation  “W . 

•  Define  Sc  =  {  (  R\{c},  Q\{c}  )  :  P  3CQ  }.  Show  that  ic is  a  weak  conformation. 

•  LSIT. 

From  LSIT  on  the  base  agents  one  derives 

S',  /=>/',  a,  I' <WS'. 

If  a  e  yt(S\{c})  then  a^c  and  .'.  S\{c}  S'\{c}. 

Now  t  contains  no  inputs  other  than  a  single  a  c. 

In  accordance  with  COR,  there  are  three  possibilities  for  c: 

(1)  c  (I),  A  (S), 

(2)  c  e  idle  ( I,S)  and 

(3)  c  €  A(S). 

Case  1.  c  £  A  (I)  and  .'.  c  £  t. 

Case  2.  c  cannot  lie  along  any  reachable  path.  Clearly  t  is  a  reachable  path.  .'.  c  <£  t. 
Case  3.  ce  A(S).  :.c£  cExtr{I,S).  All  outputs  in  t  come  from  cExtr{I,S).  :.c  <£  t. 
For  all  three  cases  c  £  t.  I\{c}  =b>/'\{c}  and  ( 7'\{c},  S'\{c}  )  e  Sc- 

•  LSO. 

Let  M  be  a  maxoctset  of  S  with  respect  to  s. 

There  are  two  cases  on  c:  (1)  c  e  s  and  (2)  c  £  s. 
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Case  1.  The  Restriction  blocks  every  x  e  M  and  the  application  of  LSO  to  is  moot. 
Case  2.  M remains  whole,  and  .'.  VieM:  S\{c}  =>5"\{c}. 

Let  t  be  the  implementation  of  Mby  I. 

Now  c  <£  t.  Otherwise,  c  e  cExtr  (I,S),  a  violation  of  COR. 

.'.  I\{c}  =>/'\{c}. 

Also,  since  c  <£  t  one  has:  t  \  J(S\{c})  =  t  \  X(S)  =  s. 

Clearly,  ( I\{c},  S"\{c}  )  e  Sc,  so  LSO  is  established. 

•  LII  and  LIOT:  Similar. 

□ 


Proof  of  Proposition  4-17. 

Define  ^  =  {  (G{I/X),  G{S/X})  :  I  =E{I/X },  S  =F{S/X)  }.  Show  that  <^is  a  weak 
conformation  up  to  >-w.  Once  that  is  established  then  G  { I/X)  X  G{S/X]  implies  that 
G{I/X}  >-w  G\S/X).  In  particular,  when  G\X)  =X  one  derives  /  >-w  S.  To  show  (R  lo  be  a 
weak  conformation  up  to  >-w  one  must  establish  each  of  the  “primed”  laws.  The  proof  of 
each  law  is  a  coinduction  on  the  structure  of  G,  also  known  as  transistion  induction 
(Milner,  1989:  Section  2.10).  The  cases  are  G  =X (recursive  definition),  G  =  a.Gl,  G  = 
Gl  +  G2,  G  =  G1\G2,  G=  Gl\{c},  G  =  Gl[f]  and  G  =  C  (a  constant  agent  having  no 
occurrences  of  X). 

•  LSIT. 

To  show,  for  a  e  A(G{S/X})  u  {r}: 

Whenever  G{S/X)  ^  Q'  then  G(l/X)  p’  >-w  Q'  where  t  \  J(G{S/Xj)  =  a . 

G  =  X. 

In  this  case  G{S/X}  =  S. 

Let  G{S/X]  =  Q'  and  consider  the  inference  that  established  this  transition. 

clef 

It  arises  from  application  of  Con,  where  the  side  condition  is  S  =  F{S/X). 
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Hence,  by  a  shorter  inference,  F{S/X)  -G  Q\ 

By  coinduction,  F\ I/X)  P'  >-w  (Rpw  Q'  where  t  i  J4(F\S/X}  )  =  a . 

Now  apply  E  F.  E{I/X}  >-w  F{I/X) . 

Since  F{I/X}  P'  then  E{I/X}  implements  t  with  some  u: 

t  contains  at  most  one  input  a  amidst  extraneous  ouputs.  i.e.  t  =  t'.a  .t" 
u  =  u'.u".u"'  arises  by  serial  application  of  LSOS,  LSIT  and  LSOS. 
u'  \  J (. F{I/X })  =conf  t'.  u"\A(F{I/X})  =  a.  u'"\J (1 F{I/X })  =conf  t’" 
Hence  E{I/X}±>  O'^P' . 

But  G{I/X]  =  /  =  E{I/X]  so  G{I/X)  O', 
u  \  A(F{S/X })  =  a . 

O'  P'  Q’.  That  is,  O'  <2?>w  Q'. 

Hence  LSIT'  is  established  for  the  case  G=X. 

G  =  a.Gl. 

G{S/X)  =  a.GI  {S/X}  -G  G1{S/X}  and  G{I/X }  =  a.Gl{I/X)  G^  G1{I/X } 
Clearly,  G I  {I/X}  <RGl{S/X). 

G  =  G1  +  G2. 

Let  G{S/X)  -GQ'.  The  transition  arises  from  Sum. 

By  a  shorter  inference,  G1  {S/X}  GQ'  ovG2{S/X}  GQ'. 

W.l.o.g.  assume  the  fonner. 

By  coinduction,  G1  { I/X}  G P '  >w  RJXw  Q'  for  I  I"  A(G1  {S/X})  =  a . 
t  \  A(G\S/X}  )  =  a  since  t  contains  no  inputs  but  a . 

G{I/X}  GPGw  Ryw  Q'  by  Sum. 

G  =  G1\G2. 

Let  G{S/X}  G  Q'.  The  transition  arises  from  Coml,  2  or  3. 

Coml. 

By  a  shorter  inference,  and  w.l.o.g.,  G1  { S/X}  G  Q1 '. 

By  coinduction  G1  {I/X}  G  P1GW  Xhw  Q1 '  for  1 1  A{G1  {S/X})  =  a 


B-9 


t  \  MG  {S/X})  =  a  since  t  contains  no  inputs  but  a . 

Thus  G {I/X}  X  PI  '|  G2  {I/X}  when  G{S/X)M  Q1  '\  G2  {I/X) 

It  remains  to  show  that  PI  '\  G2  { I/X)  >-w  (Rpw  Q1  '\  G2  {I/X) . 

Write  PI '  >-w  XM  Q1  ’  as  PI '  PI "  X  Q1  "Xv  Q1 
PI "  (R,  Q1 "  means  3H1  {X}  such  that 
PI "  =  HI  {I/X}  and  Q1 "  =  HI  { S/X } . 

Set  H=H1\G2. 

P1'\G2{I/X)  twPl"\G2{I/X)  =  H{I/X)  RJI{S/X)  and 

H{S/X}=  Q1'\G2{I/X}>W  Ql'\G2{I/X) 

Thus  P1 1 G2  {I/X)  >-w  R,  Q1  '\  G2  {I/X) . 

Com2.  Similar. 

Com3.  By  a  shorter  inference,  Gl  {S/X}  W  Q1 G2{S/X)  W  Q2 
W.l.o.g.,  a  is  an  input  action  and  a  is  its  output  coaction. 

By  coinduction,  LSIT’  applies  to  the  former,  and  LSO’  applies  to  the  latter. 
Gl  { I/X)  and  G2{I/X)  implement  with  strings  containing  a  and  a  . 

This  situation  was  faced  in  the  proof  of  Proposition  4-13,  LSIT,  Case  2. 
The  proof  that: 

(  Gl  {S/X)  |  G2{S/X)  )^>{Q1'\  Q2') 

(  Gl { I/X)  |  G2{I/X) )  ^>  (P1'\P2') 

Gl  {S/X)  |  G2{S/X) )  =  £• 
is  analogous  to  that  of  Proposition  4-13,  where 
Gl  {S/X) plays  the  role  of  S,  Ql'oIS', 

G2{S/X)  of  T,  (Q2GX  T\ 

Gl  {I/X)  of  I,  PI' of  I', 

G2{S/X)  of  J  and  P2 '  of  T. 

By  coinduction  both 

Pl'twXhwQl' 
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and 


P2'yw<tiywQ2'. 

Writing  them  as 

PI ' >-w HI '{I/X} pill '{S/X}  >-w  Q1 ' 

P2 '  H2  '{I/X}  P)12  '{S/X}  >-w  Q2 ' 

one  has 

(P1'\P2'  )  ( HI  '{I/X}  |  H2  '{I/X} )  by  Proposition  4-13, 

( HI  '{I/X}  |  H2'{I/X })  (R,  (HI' {S/X}  \  H2'{S/X })  by  definition  of  <£ 
( HI '{S/X}  |  //2'{SZ¥}  )>w  (  Ql’\  Q2' )by  Proposition  4-13 
from  which  follows: 

(Pr\P2')yw<Hhw(Ql'\Q2'). 

This  proof  that  >-w  R  yxv  applies  to  the  derivatives  of  a  composite  agent  follows  a  single 
scheme,  as  can  by  seen  in  the  Coml  and  Com3  cases  immediately  above.  The  scheme  is 
as  follows: 

(1)  Take  the  Vw  (k>w’  relation(s)  of  the  non-composite  derivatives. 

(2)  Introduce  expression(s)  H  to  fill  in  between  Vw’  and  ‘  1/ . 

(3)  Form  a  composite  H. 

(4)  Invoke  the  proposition  that  states  that  the  operator  in  question  preserves  weak 
conformation. 

(5)  Show  that  the  composite  deriviatives  share  Vw’  with  the  composite  H. 

(6)  Note  that  (  composite  H{I/X},  composite  II \  S/X}  )  e  (R, 

(6)  Combine  results  to  show  that  the  composite  derivatives  share  Vw  ppP. 
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This  scheme  will  be  frequently  reused,  and  is  now  called  the  composite  H  scheme. 


G  =  Gl\{c}. 

G{S/X}=Gl{S/X}\{c }  40'. 

The  transition  arises  from  application  of  Res  with  the  side  condition  c. 

By  a  shorter  inference  Gl  {S/X]  4  Q"  and  hence  Q'  =  Q"\{c}. 

By  induction  Gl  {I/X}  4 P "  yw  Rjyw  Q"  for  t  \  JL(G1  {S/X})  =  a . 

The  case  analysis  on  c  in  Proposition  4-14  applies  here,  and  c?t 
Hence  Gl{I/X}\{c}±>P"\{c} 

P'\{c}  yw  Rjyw  Q'\{c}  is  shown  by  means  of  the  composite  H  scheme. 

G=  Gl[f. 

G{S/X}=Gl{S/X}[f]  /(4  Q'\f] 

The  transition  arises  by  application  of  Rel. 

By  a  shorter  inference,  Gl  {S/X}  4  Q'. 

By  induction,  Gl  {I/X}  i>Pfyw  (RPw  Q'. 

By  Rel  G{I/X)  f%  P'[f\. 

P'[f]  yw  Rjy w  Q'[f]  is  shown  by  means  of  the  composite  H  scheme. 

G=C. 

G{I/X}  =  G{S/X}  and  the  satisfaction  of  LSIT’  is  trivial. 

•  LSO'. 

To  show  that  Vmaxoctsets  Mof  G(S/X): 

G(I/X}  ±>P'yw  Ryw  Q'  where  G{S/X}  4 Q'  and  t  (  J  (G{S/X})  =  s. 

G  =  X. 

G{S/X}  =  S  and  .S’  =  F{S/X}. 

Vm  e  M,  whenever  S=>~Q'  then  F{S/X}  =>~0'  by  shorter  inferences.1 
Hence  F{S/X}  has  a  maxocset  M. 

1  Since  the  transition  rules  derive  atomic  transitions,  multiple  applications  are  required  to  infer  a  string 
transition. 
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By  coinduction,  F{l/X)  =>/*'  >w  R  >-w  Q'  where  t  \  A  (F\S/X)  =  s  e  M. 
t  defines  a  maxoctset  M'  for  F{I/X)  by  Proposition  3-6. 

Apply  E  >-w  F.  E{I/X}  >-w  F\I/X) . 

By  LSO,  E{I/X)  implements  M'  with  some  u  where  u  \  A  {F{I/X})  =conf  t. 

Hence  E{I/X)  i>OAwP' 

But  G{I/X)  =1  =  E{I/X)  so  G\l/X)  ^0'. 

Since  u  \  A  ( F{I/X) )  =conf  t  then 

u  \  J  C F{S/X })  =  ut  A  (. F{I/X })  1  J  (F{S/X\)  =  s'=confS. 
s'  e  M  for  the  same  reasons  thatx  e  Xin  the  proof  of  Proposition  3-7. 

Now  O'  yw  P'  >-w  (KXw  Q'  and  hence  O'  >-w  0'. 

G  =  a.Gl. 

Let  G ! S/X}  =  a.Gl  {S/X}  have  maxoctset  M  with  respect  to  m,  tenninating  at  Q’. 
a  must  be  an  output  action  and  must  appear  first  in  every  string  of  M. 

G1 1 S/X  [  has  maxoctset  Ml  with  respect  to  mi,  where  m  =  a.mi. 

Ml  also  terminates  at  Q’. 

By  coinduction,  Gl{I/X}^P’x w  ItXw  Q' where  t\  A(G1  {S/X})  =  s  e  Ml. 

Hence  G{I/X)  =>P’  and  G\S/X}=>Q'. 
a.t  \  A  ( a.Gl  {S/X})  =  a.s  e  M. 

P'hw  XXw  Q'  is  already  established. 

G  =  G1  +  G2. 

When  G{S/X}  has  maxoctset  M  then  by  Lemma  4-10,  M  =  Ml  u  M2  where 
Ml  is  a  maxoctset  of  G1  {S/X}  and  M2  is  a  maxoctset  of  G2  {S/X} . 

By  coinduction,  G1  {I/X}  implements  Ml  with  t: 

G1  {I/X}  ±>P',G1  {S/X}  =b Q’,s  e  Ml,  t\J (G1  {S/X})  =  s,  P' XXw  Q’. 
By  Sum,  G{I/X}  ±>P'  and  G{S/X}  ^  Q'. 

t  \  A  (G\S/X}  )  =  s  unless  A  ( G2{I/X })  contains  actions  in  ‘Eytr  (  G{I/X}, 

G{S/X }). 
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Yet  PEA  assures  that  no  a  is  in  both  J4  ( G2 { I/X} )  and ‘Extr  (  G  { I/X) . 

t\  J(G{S/X))  =  s. 

P'  Aw  Q'  is  already  known. 

(The  case  where  G2  { I/X)  implements  M2  is  similar,  but  unneeded.) 

G=G1\G2. 

When  G{S/X)  has  maxoctset  Mwith  respect  to  m  then  by  Lemma  4-12, 

G1 !  S/X)  has  maxoctset  Ml  with  respect  to  m  / 

G2  { S/X)  has  maxoctset  M2  with  respect  to  m2, 
where  m  =COnf  mi. m2 

By  coinduction,  G1{I/X)  implements  Ml  with  tf. 

G1  {I/X)  hPl ',  G1  {S/X)  /XQV,  t/\J ( G1  {S/X))  =  Sl  e  Ml,  PI '  Yw  Q1 ' 
and  G2{I/X)  implements  M2  with  tf. 

G2{I/X)  =>P2\  G2{S/X)  ■=>  Q2\  t2  t  J(G2{S/X))  =  s2  e  M2,  P2'yw  <2(>w  Q2'. 
Now  G{I/X)  h  =>P1  '\P2',  G{S/X)  =>  2/>Ql'\ Q2 ',  t,  ,t2  \  J(G{S/X})  =  Sl.s2eM. 
PI '  | P2 '  Yw  Aw  Q1 1 Q2 '  is  shown  by  the  composite  H  scheme. 

G=Gl\{c). 

Let  G{S/X)=  G1  {SZ¥}\{c}  have  maxoctset  M  with  respect  to  m  terminating  at  Q'. 
Since  all  strings  in  a  maxoctset  are  =COnf,  \{c}  blocks  every  string,  or  none  of 

them. 

Hence  Restriction  preserves  every  maxoctset  that  it  does  not  delete  entirely. 

.'.  c  £  m,  and  M  is  a  maxoctset  of  G1  {S/X} . 

By  coinduction,  G1{I/X)  implements  M  with  t: 

G1  {I/X)  ±>P1 '  Aw  <^Aw  Q1 G1  {S/X)  Q1 ',  and  t\  *  (G1  {S/X})  =  s  e  M. 
To  prove  that  G1  {I/X)\{c}  b>Pl '  \{c}  one  must  be  assured  that  c  <£  t. 

Trial  Hypothesis .  Assume  c  e  t. 

Now  c  <£  s  since  s  survived  the  Restriction. 

.-.  c  e  Txtr{Gl{I/X),  G1{S/X)). 
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COR  requires  that  only  idle  extraneous  outputs  can  be  Restricted. 
Lying  along  an  implementing  path  t,  the  c  is  manifestly  not  idle. 


Hence  G1  {. I/X}\{c }  bPl ' \{c}  and  t\  a ( G1  {S/X}\{c})  =  s. 

PI '  \{c}  >:w  Xhw  Q1 ' \{c}  is  shown  using  the  composite  P[  scheme. 

G  =  Gl[f]. 

BR  assures  that/"1  exists  and  is  bijective. 

If  G1  {S/X}[[  has  maxoctset  M  then  G1{S/X)  has  maxocsetMl/’1]. 

By  coinduction,  G /  { I/X}  implements  with  t\ 

G1  {I/X}  =>PI'yK  Xhw  Q1 where  G1  {S/X}  =L Q1 ' and 
t\J(Gl{S/X})  =  s  eM\fA]. 

Hence, 

G1  {I/X}  [f]  %P1 '  [f]  where  Gl  \S/X\  [/]  Q1 '[/] 
At)\J{Gl{S/X}\f])=j{s)^M. 

To  show  Pl'\fy w  Xhw  Q1 '[/]  use  the  composite  H  scheme. 

G=C. 

G{I/X}  =  G{S/X}  and  the  satisfaction  of  LSIT’  is  trivial. 

•  LIP. 

To  showVye  JZ(G{S/X }) 

Whenever  G{I/X}  /C and  G{S/X}  b  then  G\S/X{  b  Q’  where  P'  >-w  <R>W  Q'. 
G  =  X. 

G{I/X}  =I=E{I/X} 

When  G{S/X}  b  the  actions  are  inferred  from  Con  where  S  =  F{S/X}. 

By  a  shorter  inference  F{S/X}  b . 

Now  E{S/X}  >-w  F{S/X}  so  LSAI  requires  that  E\S/X\  b . 

When  G  | I/X}  =  lb  P'  the  action  is  inferred  from  Con,  where  /  =  E{I/X} . 

By  a  shorter  inference,  E{I/X}  bP'. 
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Since  E{S/X)  b  then  by  coinduction,  E{S/X)  b  Q'  with  P'  Q'. 

Now  E{S/X)  >-w  F{5ZA},  and  since  F{S/X)  b  one  may  apply  LII. 

F{S/X)  b R '  where  QbwR'. 

So  G{I/X}  =  /  =  £{//X}  4  P'  and  G{S/X]  =  5  =  F{S/X}  =>/?'. 

P'  >:w  <2^w  0  Vw  P' ,  or  more  simply,  P'  Ryw  R' . 

G  =  a.Gl. 

a  is  an  input. 

Clearly  G{I/X}  ^  G1  {I/X} ,  G{S/X)  b  Gl  {S/X)  and  Gl  {S/X}  R.G!  {S/X) . 

G  =  G1  +  G2. 

Let  G{I/X)  bP'  and  G{S/X}  b . 

By  a  shorter  inference  on  Sum,  and  w.l.o.g.,  Gl  {I/X}  b  P'. 

The  inference  that  Gl  {I/X}  b  is  independent  of  the  instantiated  agent  variable. 

.-.  Gl  {S/X}  b  or,  Gl  {S/X}  b . 

By  coinduction,  Gl  {S/X}  b  Q'  and  P'  >-w  Xhw  Q'- 
G  =  G1\G2. 

Let  G\l/X]  =  Gl  { I/X}  | G2 { I/X}  bP'  and  G{S/X}  =  Gl  {S/X} \G 2 {S/X}  b . 

By  a  shorter  inference  on  Com,  and  w.l.o.g.,  Gl  {I/X}  bP". 

Again,  Gl  {S/X}  b  since  the  inference  is  independent  of  instantiated  agent. 

By  coinduction  Gl  {S/X}  b  Q"  with  P"  Xhw  Q". 

Hence  G{I/X}  bP"  \  G2{I/X}  and  G{S/X}  b  Q"  \  G2{S/X}. 

P"  |  G2{I/X)  >>  <RJXw  Q" \G{S/X}  is  shown  using  the  composite  H  scheme. 
G=Gl\{c}. 

Let  Gl  {I/X}\{c}  bP'  and  Gl  {S/X}  =  Gl  {SZY}\{c}  b  .  y*c. 

By  shorter  inferences  on  Res,  Gl  {I/X}  bP"  and  Gl  {S/X}  b  where  P'  =  P"  \\c}. 
By  coinduction  Gl  {S/X}  b  Q"  with  P"  Rjpw  Q"- 
Hence  G{I/X}  bP"\{c}  and  G{S/X}  b  Q"\{c}. 

P"\{c}  yw  Xhw  Q"\{c }  is  shown  using  the  composite  H  scheme. 
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G  =  Gl[f] 

BR  assures  that/"1  exists  and  is  bijective. 

Let  Gl  {I/X}  \f]AP'\f]  and  G1  {S/X}  [f]  A . 

By  shorter  inferences,  G I  { I/X}  f  A  P'  and  Gl  {S/X}  'A  . 

/-'O) 

By  coinduction,  G1{S/X)  =>  Q'  where  P'  y-w  Q' • 

Hence,  Gl{S/X}[f]  AQ'[f] 

The  proof  that  P'  \f\  Aw  I/Aw  Q'  [/]  follows  the  composite  H  scheme. 

G=C. 

G{I/X)  =  G{S/X}  and  the  satisfaction  of  LIT  is  trivial. 

•  LIOT'. 

To  show  V/?  e  A  {G{I/X})  u  { r} 

If  G{I/X)  AP'  then  G{S/X)  A  Q'  where  P'  >-w  Q'  and  8=  /3\  J  (G{S/X\). 

G  =  X. 

Let  G{I/X)  =/  AP'. 

I  =  E{I/X)  so,  by  a  shorter  inference,  E{I/X}  AP'. 

By  coinduction,  E {S/X}  A  Q'  where  P'  yw  RAw  Q'  and  8=  (3\  A  {G{S/X}). 

Apply  EywF.  E{S/X}yw  F{S/X). 

By  LIOT  F{S/X\  A R '  where  Q'ywR'. 

S  =  F{S/X)  so  by  Con,  G{S/X)  =sAr'. 

P'  pw  RPw  Q'  >w  R',  so  P'  Aw 
G  =  a.Gl. 

a  is  an  output  or  z. 

G{I/X)  Gl  {I/X} ,  G{S/X)  A  Gl  {S/X} ,  a=  a\  A  (G{S/X}),  Gl  {I/X}  I/Gl  {S/X} . 
G=GI  +  G2. 

Let  Gl  {I/X}  +  G2 {I/X}  AP'. 

By  a  shorter  inference  on  Sum,  and  w.l.o.g.,  G1{I/X}  AP'. 

By  coinduction,  Gl  { S/X}  A  Q'  where  P'  Aw  Rpw  Q'  and  8=  f:l\  A  {Gl  \S/X}). 


B-17 


By  Sum,  G{S/X)  =  Gl  {S/X]  +  G2{S/X }  A  Q’. 

Since  J (Gl  {S/X})  c  A (G{S/X))  then  j3 \  J (< G{S/X })  =  8. 

P'Xw  RXw  Q'  is  already  established. 

Let  G{I/X)  bP'. 

By  a  shorter  inference  on  Com,  w.l.o.g.,  G1{I/X)  A/5"  where  P'  =  P"\G2{I/X) . 
By  coinduction,  Gl  { S/X)  b  Q"  where  P"  Aw  RXw  Q"  and  8=  J3\  A  (Gl  {SZY}). 
By  Com,  G{S/X)bQ"\G2{S/X\. 

Since  J  (Gl  {S/X})  c  A  (G{S/X{)  then  (i  \  J  (G{S/X})  =  8 
P"\G2{I/X}  Aw  XXw  Q”\G2 {S/X}  is  shown  by  the  composite  H scheme. 
G=Gl\{c}. 

Let  Gl{I/X}\{c)  bP'.  {c}. 

By  a  shorter  inference  on  Res,  Gl  {I/X}  bP"  where  P"\{c}  =  P'. 

By  coinduction,  Gl  {S/X}  b  Q"  where  P"  Aw  Xhw  Q"  and  8=  p  \J  (Gl  {S/X}). 
By  Res,  Gl{S/X}\{c}bQ' =  Q"\{c}. 
p\  A  (Gl  {<SZY}\{c})  =  8 since  {c}. 

P'\{c}  Aw  (RJtiw  Q"\{c}  is  shown  by  the  composite  PL  scheme. 

G  =  Gl[f. 

BR  assures  that f  1  exists  and  is  bijective. 

Let  Gl{I/X}[f]  bP'. 

By  a  shorter  inference  on  Rel,  Gl  {I/X}  '  A  P"  where  P'  =  P"\f{. 

By  coinduction, 

Gl  {S/X}  A  Q”  where  P"  XhwQ"  and  S=f~\jB)  \  J(G1{S/X}). 

By  Rel,  Gl  {S/X)[f]fb  Q"[f]  =  Q'. 

A8)=M~\^MG1{S/X}))=  J3\  A(Gl{S/xm=p\  A(G{S/X}). 

P"\f]  Aw  R  bw  Q”[f  ]  is  shown  by  the  composite  //  scheme. 
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G{I/X)  =  G{S/X}  and  the  satisfaction  of  LII'  is  trivial. 


□ 
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Appendix  C 


CCS  Transition  Rules  (Milner,  1989) 


Act  - 

a.E  ME 


E  M  E' 

Sum  i  - 

E  +  F  ME' 


E  E' 

Sum  2  - 

F  +  E  ME' 


E  g)  E' 

Com  i  - 

E\F  ME' \F 


E  M  E'  EME'M^E' 

Com2  -  C01113  - 

F\EMF\E'  E  I  F  ME'  I  F' 


E  M E ' 

Res  - (a,  a  <£  L) 

EEL  MEM 


E  ME' 

Rel  - 


m  r(ME'\z 


P  MP' 

Con  - (A  =  P ) 

A  MP' 


C-l 


E(fix(X  =  E))  E ' 


Rec 


fix(X  =  E )  ±>E' 


a  e  Act,  £  e  L,  A  and  B  are  agents,  E  and  F  are  agent  expressions,  and  the  restriction  set 
let. 


These  rules  are  implications  with  the  upper  transition(s)  implying  the  lower.  Side 
conditions  apply  for  the  rules  Res  and  Con.  The  Act  rule  is  universally  inferred,  having 
an  empty  premise  (truth). 
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Appendix  D 


S,  I  and  J Initial  Models 


entity  S  is 

port  (  A,  B,  C,  D  :  in  bit; 

00,  01,  02,. ..09  :  out  bit  ); 

end  S  ; 

architecture  BEHAVIOR  of  S  is 
begin 

process  (A,B,C,D) 
begin 

assert  A&B&S&D  <  "1010"; 
case  A&B&S&D  is 
when  0000  => 

00  <=  1; 

01  <=  0; 

02  <=  0; 

03  <=  0; 

04  <=  0; 

05  <=  0; 

06  <=  0; 

07  <=  0; 

08  <=  0; 

09  <=  0; 
when  0001  => 

00  <=  0; 

01  <=  1; 

02  <=  0; 

03  <=  0; 

04  <=  0; 

05  <=  0; 

06  <=  0; 

07  <=  0; 

08  <=  0; 

09  <=  0; 
when  0010  => 

00  <=  0; 

01  <=  0; 

02  <=  1; 

03  <=  0; 

04  <=  0; 

05  <=  0; 

06  <=  0; 

07  <=  0; 

08  <=  0; 

09  <=  0; 
when  0011  => 

00  <=  0; 

01  <=  0; 

02  <=  0; 

03  <=  1; 

04  <=  0; 

05  <=  0; 
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06 

<= 

0; 

07 

<= 

0; 

08 

<= 

0; 

09 

<= 

0; 

when 

0100 

= 

OO 

<= 

0; 

01 

<= 

0; 

02 

<= 

0; 

03 

<= 

0; 

04 

<= 

1; 

05 

<= 

0; 

06 

<= 

0; 

07 

<= 

0; 

08 

<= 

0; 

09 

<= 

0; 

when 

0101 

= 

OO 

<= 

0; 

01 

<= 

0; 

02 

<= 

0; 

03 

<= 

0; 

04 

<= 

0; 

05 

<= 

1; 

06 

<= 

0; 

07 

<= 

0; 

08 

<= 

0; 

09 

<= 

0; 

when 

0110 

= 

OO 

<= 

0; 

01 

<= 

0; 

02 

<= 

0; 

03 

<= 

0; 

04 

<= 

0; 

05 

<= 

0; 

06 

<= 

1; 

07 

<= 

0; 

08 

<= 

0; 

09 

<= 

0; 

when 

0111 

= 

OO 

<= 

0; 

01 

<= 

0; 

02 

<= 

0; 

03 

<= 

0; 

04 

<= 

0; 

05 

<= 

0; 

06 

<= 

0; 

07 

<= 

1; 

08 

<= 

0; 

09 

<= 

0; 

when 

1000 

= 

OO 

<= 

0; 

01 

<= 

0; 

02 

<= 

0; 

03 

<= 

0; 

04 

<= 

0; 

05 

<= 

0; 

06 

<= 

0; 

07 

<= 

0; 

08 

<= 

1; 

09 

<= 

0; 
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when 

1001 

=> 

OO 

<= 

0; 

01 

<= 

0; 

02 

<= 

0; 

03 

<= 

0; 

04 

<= 

0; 

05 

<= 

0; 

06 

<= 

0; 

07 

<= 

0; 

08 

<= 

0; 

09 

<= 

1; 

end  case; 

end  process; 
end  BEHAVIOR; 
end  behavior; 
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entity  I  is 

port  (  A,  B,  C,  D 

00,  01,  02, ...015 

end  S  ; 

architecture  BEHAVIOR  of 
begin 

process  (A,B,C,D) 
begin 

case  A&B&S&D  is 

when  0000  => 

00  <=  1; 

01  <=  0; 

02  <=  0; 

03  <=  0; 

04  <=  0; 

05  <=  0; 

06  <=  0; 

07  <=  0; 

08  <=  0; 

09  <=  0; 

010  <=  0; 

Oil  <=  0; 

012  <=  0; 

013  <=  0; 

014  <=  0; 

015  <=  0; 
when  0001  => 

00  <=  0; 

01  <=  1; 

02  <=  0; 

03  <=  0; 

04  <=  0; 

05  <=  0; 

06  <=  0; 

07  <=  0; 

08  <=  0; 

09  <=  0; 

010  <=  0; 

Oil  <=  0; 

012  <=  0; 

013  <=  0; 

014  <=  0; 

015  <=  0; 
when  0010  => 

OO  <=  0; 

01  <=  0; 

02  <=  1; 

03  <=  0; 

04  <=  0; 

05  <=  0; 

06  <=  0; 

07  <=  0; 

08  <=  0; 

09  <=  0; 

OlO  <=  0; 

Oil  <=  0; 

012  <=  0; 

013  <=  0; 

014  <=  0; 


in  bit; 
out  bit  ) 


is 


D 


015  <=  0; 
when  0011  => 
00  <=  0; 
01  <=  0; 
02  <=  0; 
03  <=  1; 
04  <=  0; 
05  <=  0; 
06  <=  0; 
07  <=  0; 
08  <=  0; 
09  <=  0; 
010  <=  0; 
Oil  <=  0; 
012  <=  0; 
013  <=  0; 
014  <=  0; 
015  <=  0; 
when  0100  => 
OO  <=  0; 
01  <=  0; 
02  <=  0; 
03  <=  0; 
04  <=  1; 
05  <=  0; 
06  <=  0; 
07  <=  0; 
08  <=  0; 
09  <=  0; 
010  <=  0; 
Oil  <=  0; 
012  <=  0; 
013  <=  0; 
014  <=  0; 
015  <=  0; 
when  0101  => 
OO  <=  0; 
01  <=  0; 
02  <=  0; 
03  <=  0; 
04  <=  0; 
05  <=  1; 
06  <=  0; 
07  <=  0; 
08  <=  0; 
09  <=  0; 
010  <=  0; 
Oil  <=  0; 
012  <=  0; 
013  <=  0; 
014  <=  0; 
015  <=  0; 
when  0110  => 
OO  <=  0; 
01  <=  0; 
02  <=  0; 
03  <=  0; 
04  <=  0; 
05  <=  0; 
06  <=  1; 
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07  <=  0; 
08  <=  0; 
09  <=  0; 
010  <=  CO- 
Oll  <=  0; 

012  <=  co¬ 
on  <=  0; 

014  <=  0; 
015  <=  0; 
when  0111  => 
OO  <=  0; 
01  <=  0; 
02  <=  0; 
03  <=  0; 
04  <=  0; 
05  <=  0; 
06  <=  0; 
07  <=  1; 
08  <=  0; 
09  <=  0; 
010  <=  0; 
Oil  <=  0; 
012  <=  0; 
013  <=  0; 
014  <=  0; 
015  <=  0; 
when  1000  => 
OO  <=  0; 
01  <=  0; 
02  <=  0; 
03  <=  0; 
04  <=  0; 
05  <=  0; 
06  <=  0; 
07  <=  0; 
08  <=  1; 
09  <=  0; 
010  <=  0; 
Oil  <=  0; 
012  <=  0; 
013  <=  0; 
014  <=  0; 
015  <=  0; 
when  1001  => 
OO  <=  0; 
01  <=  0; 
02  <=  0; 
03  <=  0; 
04  <=  0; 
05  <=  0; 
06  <=  0; 
07  <=  0; 
08  <=  0; 
09  <=  1; 
010  <=  0; 
Oil  <=  0; 
012  <=  0; 
013  <=  0; 
014  <=  0; 
015  <=  0; 


D-6 


when  1010  => 
00  <=  0; 
01  <=  0; 
02  <=  0; 
03  <=  0; 
04  <=  0; 
05  <=  0; 
06  <=  0; 
07  <=  0; 
08  <=  0; 
09  <=  0; 
OlO  <=  1; 
Oil  <=  0; 
012  <=  0; 
013  <=  0; 
014  <=  0; 
015  <=  0; 
when  1011  => 
OO  <=  0; 
01  <=  0; 
02  <=  0; 
03  <=  0; 
04  <=  0; 
05  <=  0; 
06  <=  0; 
07  <=  0; 
08  <=  0; 
09  <=  0; 
OlO  <=  0; 
Oil  <=  1; 
012  <=  0; 
013  <=  0; 
014  <=  0; 
015  <=  0; 
when  1100  => 
OO  <=  0; 
01  <=  0; 
02  <=  0; 
03  <=  0; 
04  <=  0; 
05  <=  0; 
06  <=  0; 
07  <=  0; 
08  <=  0; 
09  <=  0; 
OlO  <=  0; 
Oil  <=  0; 
012  <=  1; 
013  <=  0; 
014  <=  0; 
015  <=  0; 
when  1101  => 


OO 

<= 

0; 

01 

<= 

0; 

02 

<= 

0; 

03 

<= 

0; 

04 

<= 

0; 

05 

<= 

0; 

06 

<= 

0; 

07 

<= 

0; 
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08  <=  0; 

09  <=  0; 

010  <=  CO- 
Ol  1  <=  0; 

012  <=  0; 

013  <=  1; 

014  <=  0; 

015  <=  0; 
when  1110  => 

OO  <=  0; 

01  <=  0; 

02  <=  0; 

03  <=  0; 

04  <=  0; 

05  <=  0; 

06  <=  0; 

07  <=  0; 

08  <=  0; 

09  <=  0; 

010  <=  0; 

Oil  <=  0; 

012  <=  0; 

013  <=  0; 

014  <=  1; 

015  <=  0; 
when  1111  => 

OO  <=  0; 

01  <=  0; 

02  <=  0; 

03  <=  0; 

04  <=  0; 

05  <=  0; 

06  <=  0; 

07  <=  0; 

08  <=  0; 

09  <=  0; 

010  <=  0; 

Oil  <=  0; 

012  <=  0; 

013  <=  0; 

014  <=  0; 

015  <=  1; 
end  case; 
end  process; 
end  BEHAVIOR; 
entity  J  is 

port  (  A,  B,  C,  D  :  in  bit; 

OO,  01,  02, ...015  :  out  bit  ); 

end  S  ; 

architecture  BEHAVIOR  of  J  is 

constant  DELAYO,  DELAY1 ,  DELAY2 ,  DELAY3 , 

DELAY 4 ,  DELAY5 ,  DELAY 6,  DELAY 7 , 

DELAY 8 ,  DELAY 9,  DELAY10,  DELAY11, 

DELAY12 ,  DELAY13,  DELAY14 ,  DELAY 15 

:  time; 

begin 

process  (A,B,C,D) 
begin 
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case  A&B&S&D  is 

when  0000  => 

00  <=  1  after  DELAYO; 

01  <=  0  after  DELAY1 ; 

02  <=  0  after  DELAY2 ; 

03  <=  0  after  DELAY3 ; 

04  <=  0  after  DELAY 4 ; 

05  <=  0  after  DELAY5 ; 

06  <=  0  after  DELAY 6; 

07  <=  0  after  DELAY 7 ; 

08  <=  0  after  DELAY 8 ; 

09  <=  0  after  DELAY 9; 

010  <=  0  after  DELAY10; 

Oil  <=  0  after  DELAY11; 

012  <=  0  after  DELAY 12 ; 

013  <=  0  after  DELAY13; 

014  <=  0  after  DELAY 14 ; 

015  <=  0  after  DELAY15; 

when  0001  => 

OO  <=  0  after  DELAYO; 

01  <=  1  after  DELAY1 ; 

02  <=  0  after  DELAY2 ; 

03  <=  0  after  DELAY3 ; 

04  <=  0  after  DELAY 4 ; 

05  <=  0  after  DELAY5 ; 

06  <=  0  after  DELAY 6; 

07  <=  0  after  DELAY 7 ; 

08  <=  0  after  DELAY 8 ; 

09  <=  0  after  DELAY 9; 

010  <=  0  after  DELAY10; 

Oil  <=  0  after  DELAY11; 

012  <=  0  after  DELAY 12 ; 

013  <=  0  after  DELAY13; 

014  <=  0  after  DELAY 14 ; 

015  <=  0  after  DELAY15; 

when  0010  => 

OO  <=  0  after  DELAYO; 

01  <=  0  after  DELAY1 ; 

02  <=  1  after  DELAY2 ; 

03  <=  0  after  DELAY3 ; 

04  <=  0  after  DELAY 4 ; 

05  <=  0  after  DELAY5 ; 

06  <=  0  after  DELAY6; 

07  <=  0  after  DELAY 7 ; 

08  <=  0  after  DELAY8 ; 

09  <=  0  after  DELAY9; 

010  <=  0  after  DELAY10; 

Oil  <=  0  after  DELAY11; 

012  <=  0  after  DELAY 12 ; 

013  <=  0  after  DELAY13; 

014  <=  0  after  DELAY 14 ; 

015  <=  0  after  DELAY15; 

when  0011  => 

OO  <=  0  after  DELAYO; 

01  <=  0  after  DELAY1 ; 

02  <=  0  after  DELAY2 ; 

03  <=  1  after  DELAY3 ; 

04  <=  0  after  DELAY 4 ; 

05  <=  0  after  DELAY5 ; 
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06  <=  0  after  DELAY 6; 

07  <=  0  after  DELAY 7 ; 

08  <=  0  after  DELAY 8 ; 

09  <=  0  after  DELAY 9; 
010  <=  0  after  DELAY10; 
Oil  <=  0  after  DELAY11; 
012  <=  0  after  DELAY 12 ; 
013  <=  0  after  DELAY13; 
014  <=  0  after  DELAY 14 ; 
015  <=  0  after  DELAY15; 
when  0100  => 

OO  <=  0  after  DELAYO; 

01  <=  0  after  DELAY1 ; 

02  <=  0  after  DELAY2 ; 

03  <=  0  after  DELAY3 ; 

04  <=  1  after  DELAY 4 ; 

05  <=  0  after  DELAY5 ; 

06  <=  0  after  DELAY 6; 

07  <=  0  after  DELAY 7 ; 

08  <=  0  after  DELAY8 ; 

09  <=  0  after  DELAY 9; 
010  <=  0  after  DELAY10; 
Oil  <=  0  after  DELAY11; 
012  <=  0  after  DELAY 12 ; 
013  <=  0  after  DELAY13; 
014  <=  0  after  DELAY 14 ; 
015  <=  0  after  DELAY15; 
when  0101  => 

OO  <=  0  after  DELAYO; 

01  <=  0  after  DELAY1 ; 

02  <=  0  after  DELAY2 ; 

03  <=  0  after  DELAY3 ; 

04  <=  0  after  DELAY 4 ; 

05  <=  1  after  DELAY5 ; 

06  <=  0  after  DELAY 6; 

07  <=  0  after  DELAY 7 ; 

08  <=  0  after  DELAY8 ; 

09  <=  0  after  DELAY9 ; 
010  <=  0  after  DELAY10; 
Oil  <=  0  after  DELAY11; 
012  <=  0  after  DELAY 12 ; 
013  <=  0  after  DELAY13; 
014  <=  0  after  DELAY 14 ; 
015  <=  0  after  DELAY15; 
when  0110  => 

OO  <=  0  after  DELAYO; 

01  <=  0  after  DELAY1 ; 

02  <=  0  after  DELAY2 ; 

03  <=  0  after  DELAY3 ; 

04  <=  0  after  DELAY 4 ; 

05  <=  0  after  DELAY5 ; 

06  <=  1  after  DELAY 6; 

07  <=  0  after  DELAY 7 ; 

08  <=  0  after  DELAY8 ; 

09  <=  0  after  DELAY9 ; 
010  <=  0  after  DELAY10; 
Oil  <=  0  after  DELAY11; 
012  <=  0  after  DELAY 12 ; 
013  <=  0  after  DELAY13; 
014  <=  0  after  DELAY 14 ; 
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015  <=  0  after  DELAY15; 
when  0111  => 

OO  <=  9  after  DELAYO; 

01  <=  0  after  DELAY1 ; 

02  <=  0  after  DELAY2 ; 

03  <=  0  after  DELAY3 ; 

04  <=  0  after  DELAY 4 ; 

05  <=  0  after  DELAY5 ; 

06  <=  0  after  DELAY 6; 

07  <=  1  after  DELAY 7 ; 

08  <=  0  after  DELAY8 ; 

09  <=  0  after  DELAY 9; 
010  <=  0  after  DELAY10; 
Oil  <=  0  after  DELAY11; 
012  <=  0  after  DELAY 12 ; 
013  <=  0  after  DELAY13; 
014  <=  0  after  DELAY 14 ; 
015  <=  0  after  DELAY15; 
when  1000  => 

OO  <=  0  after  DELAYO; 

01  <=  0  after  DELAY1 ; 

02  <=  0  after  DELAY2 ; 

03  <=  0  after  DELAY3 ; 

04  <=  0  after  DELAY 4 ; 

05  <=  0  after  DELAY5 ; 

06  <=  0  after  DELAY 6; 

07  <=  0  after  DELAY 7 ; 

08  <=  1  after  DELAY8 ; 

09  <=  0  after  DELAY 9; 
010  <=  0  after  DELAY10; 
Oil  <=  0  after  DELAY11; 
012  <=  0  after  DELAY 12 ; 
013  <=  0  after  DELAY13; 
014  <=  0  after  DELAY 14 ; 
015  <=  0  after  DELAY15; 
when  1001  => 

OO  <=  0  after  DELAYO; 

01  <=  0  after  DELAY1 ; 

02  <=  0  after  DELAY2 ; 

03  <=  0  after  DELAY3 ; 

04  <=  0  after  DELAY 4 ; 

05  <=  0  after  DELAY5; 

06  <=  0  after  DELAY 6; 

07  <=  0  after  DELAY 7 ; 

08  <=  0  after  DELAY8 ; 

09  <=  1  after  DELAY 9; 
010  <=  0  after  DELAY10; 
Oil  <=  0  after  DELAY11; 
012  <=  0  after  DELAY 12 ; 
013  <=  0  after  DELAY13; 
014  <=  0  after  DELAY 14 ; 
015  <=  0  after  DELAY15; 
when  1010  => 

OO  <=  0  after  DELAYO; 

01  <=  0  after  DELAY1 ; 

02  <=  0  after  DELAY2 ; 

03  <=  0  after  DELAY3 ; 

04  <=  0  after  DELAY 4 ; 

05  <=  0  after  DELAY5; 

06  <=  0  after  DELAY 6; 
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07  <=  0  after  DELAY 7 ; 

08  <=  0  after  DELAY8 ; 

09  <=  0  after  DELAY 9; 
010  <=  1  after  DELAY10; 
Oil  <=  0  after  DELAY11; 
012  <=  0  after  DELAY 12 ; 
013  <=  0  after  DELAY13; 
014  <=  0  after  DELAY 14 ; 
015  <=  0  after  DELAY15; 
when  1011  => 

OO  <=  0  after  DELAYO; 

01  <=  0  after  DELAY1 ; 

02  <=  0  after  DELAY2 ; 

03  <=  0  after  DELAY3 ; 

04  <=  0  after  DELAY 4 ; 

05  <=  0  after  DELAY5 ; 

06  <=  0  after  DELAY 6; 

07  <=  0  after  DELAY 7 ; 

08  <=  0  after  DELAY8 ; 

09  <=  0  after  DELAY 9; 
010  <=  0  after  DELAY10; 
Oil  <=  1  after  DELAY11; 
012  <=  0  after  DELAY 12 ; 
013  <=  0  after  DELAY13; 
014  <=  0  after  DELAY 14 ; 
015  <=  0  after  DELAY15; 
when  1100  => 

OO  <=  0  after  DELAYO; 

01  <=  0  after  DELAY1 ; 

02  <=  0  after  DELAY2 ; 

03  <=  0  after  DELAY3 ; 

04  <=  0  after  DELAY 4 ; 

05  <=  0  after  DELAY5 ; 

06  <=  0  after  DELAY 6; 

07  <=  0  after  DELAY 7 ; 

08  <=  0  after  DELAY8 ; 

09  <=  0  after  DELAY 9; 
010  <=  0  after  DELAY10; 
Oil  <=  0  after  DELAY11; 
012  <=  1  after  DELAY 12 ; 
013  <=  0  after  DELAY13; 
014  <=  0  after  DELAY 14 ; 
015  <=  0  after  DELAY15; 
when  1101  => 

OO  <=  0  after  DELAYO; 

01  <=  0  after  DELAY1 ; 

02  <=  0  after  DELAY2 ; 

03  <=  0  after  DELAY3 ; 

04  <=  0  after  DELAY 4 ; 

05  <=  0  after  DELAY5 ; 

06  <=  0  after  DELAY 6; 

07  <=  0  after  DELAY 7 ; 

08  <=  0  after  DELAY8 ; 

09  <=  0  after  DELAY 9; 
010  <=  0  after  DELAY10; 
Oil  <=  0  after  DELAY11; 
012  <=  0  after  DELAY 12 ; 
013  <=  1  after  DELAY13; 
014  <=  0  after  DELAY 14 ; 
015  <=  0  after  DELAY15; 
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when  1110  => 

00  <=  0  after  DELAYO; 

01  <=  0  after  DELAY1 ; 

02  <=  0  after  DELAY2 ; 

03  <=  0  after  DELAY3 ; 

04  <=  0  after  DELAY 4 ; 

05  <=  0  after  DELAY5 ; 

06  <=  0  after  DELAY 6; 

07  <=  0  after  DELAY 7 ; 

08  <=  0  after  DELAY8 ; 

09  <=  0  after  DELAY 9; 
010  <=  0  after  DELAY10; 

Oil  <=  0  after  DELAY11; 

012  <=  0  after  DELAY 12 ; 

013  <=  0  after  DELAY13; 

014  <=  1  after  DELAY 14 ; 

015  <=  0  after  DELAY15; 

when  1111  => 

OO  <=  0  after  DELAYO; 

01  <=  0  after  DELAY1 ; 

02  <=  0  after  DELAY2 ; 

03  <=  0  after  DELAY3 ; 

04  <=  0  after  DELAY 4 ; 

05  <=  0  after  DELAY5 ; 

06  <=  0  after  DELAY 6; 

07  <=  0  after  DELAY 7 ; 

08  <=  0  after  DELAY 8 ; 

09  <=  0  after  DELAY 9; 
010  <=  0  after  DELAY10; 

Oil  <=  0  after  DELAY11; 

012  <=  0  after  DELAY 12 ; 

013  <=  0  after  DELAY13; 

014  <=  0  after  DELAY 14 ; 

015  <=  1  after  DELAY15; 

end  case; 
end  process; 
end  BEHAVIOR; 
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Appendix  E 


S,I  and  J  Target  Modesl 


def 

S_Behavior_Default_0  = 

s  behavior  def ault  af  's_behavior_default_oO\  's_behavior_default_ol).S  Behavior _Default_l 
+  s_behavior_default_b.(  's_behavior_default_oO\  s_behavior_default_o2).S  Behavior _Default_2 
+  s_behavior_default_c.(  's_behavior_default_oO\  's_behavior_default_o4).S_Behavior_Defaidt_4 
+  s _behavior_default_d.{'s_behavior  default _oO\  's_behavior_default_o8).S_Behavior_Defaidt_8 

def 

S_Behavior_Default_l  = 

s  behavior  default  af  's_behavior_default_ol  \  's_behavior_default_oO).S  Behavior _Default_0 
+  s_behavior_defaull_b.( 's  behavior  def  aultol  \  's_behavior_default_o3).S_Behavior_Defaidt_3 
+  s_behavior_default_c.( 's  behavior  def  aultol  \  's_behavior_defaidt_o5).S_Behavior_Default_5 
+  s_behavior_default_d.{  's_behavior_default_ol  \  's_behavior_defaidt_o9).S_Behavior_Default_9 

def 

S_Behavior_Default_2  = 

s  behavior  default  af  's_behavior_default_o2  \  's_behavior_default_o3).S  Behavior _Default_3 
+  s_behavior_default_b.(  's_behavior_default_o2  \  's_behavior_default_oO).S_Behavior_pefault_0 
+  s_behavior_default_c.{ 's  behavior  def ault_o2  \  's_behavior_defaidt_o6).S_Behavior_Defaidt_6 

def 

S_Behavior_Default_3  = 

s  behavior  default  a.  (  's_behavior_default_o3  \  's_behavior_default_o2).S  Behavior _Default_2 
+  s_behavior_default_b.( 's  behavior  def ault  o 3  \  's_behavior_defaidt_ol).S_Behavior_Default_l 
+  s_behavior_default_c.(  's_behavior_default_o3  \  's_behavior_default_o7).S_Behavior_Default_7 

def 

S_Behavior_Default_4  = 

s  behavior  def ault  af  ’s_behavior_default_o4  \  's_behavior_default_o5).S_Behavior_Default_5 
+  s_behavior_default_b.(  's_behavior_default_o4  |  's_behavior_defaidt_o6).S_Behavior_Default_6 
+  s_behavior_default_c.(  's_behavior_default_o4  \  6o).S_Behavior_Default_0 
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def 

S_Behavior_Default_5  = 

s  behavior  def ault  af  ’s_behavior_default_o5  \  's_behavior_default_o4).S_Behavior_Default_4 
+  s_behavior_default_b.( 's  behavior  def ault  o 5  \  's_behavior_default_o7).S_Behavior_Default_7 
+  s  behavior  def ault  cf  's_behavior_default_o5  \  's_behavior_default_ol).S_Behavior_Default_l 

def 

S_Behavior_Default_6  = 

s  behavior  default  a .(  's_behavior_default_o6  \  's_behavior_default_o7).S  Behavior _Default_7 
+  s_behavior_default_b.(  's_behavior_default_o6  \  's_behavior_default_o4).S_Behavior_Default_4 
+  s_behavior_default_c.( 's  behavior  def ault_o6  \  's_behavior_default_o2).S_Behavior_Default_2 

def 

S_Behavior_Default_7  = 

s  behavior  def ault  af  's_behavior_default_o7  \  's_behavior_default_o6).S_Behavior_Defaidt_6 
+  s_behavior_default_b.(  's_behavior_default_o7  \  's_behavior_defaidt_o5).S_Behavior_Default_5 
+  s  behavior  def ault  cf 's  behavior  def ault_o7  \  's_behavior_defaidt_o3).S_Behavior_Default_3 

def 

S_Behavior_Default_8  = 

s  behavior  def ault  af  's_behavior_default_o8  \  's_behavior_default_o9).S_Behavior_Defaidt_9 
+  s_behavior_default_d.(  's_behavior_default_o8  \  's_behavior_default_oO).S_Behavior_Defaidt_0 

d£ 

S_Behavior_Default_9  ~ 

s  behavior  default  a.  (  's_behavior_default_o9  \  's_behavior_defaidt_o8).S_Behavior_Default_8 
+  s_behavior_default_d.(  's_behavior_default_o9  \  's_behavior_default_ol).S_Behavior_Default_l 
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def 

I_Behavior_Default_0  = 

ibeha viordefaulla. (  'i_behavior_default_oO\  'ibehavior def ault  ol). 1 Behavior  Default _1 
+  i  behavior _default_b.{  'i_behavior_default_oO\  i_behavior_defciult_o2).  1 Behavior _Default_2 
+  i _behavior _default_c.(  'i_behavior_default_oO\  'i_behavior_default_o4).I_Behcivior_Default_4 
+  i  behavior _de:fault_dfi  behavior _de:faull_oO\  'i_behavior _default_o8). I  Behavior _Default_8 

def 

I_Behavior_Default_l  = 

i_behavior_default_a.(  'i  behavior  default  ol  \  'i_behavior _default_oO).I  Behavior _Default_0 
+  i_behavior_default_b.(  'i  behavior  default  ol  \  'i  behavior  default _o3). 1 Behavior _Default_3 
+  i  behavior  default  cf  'i  behavior  default  ol  \  'i_behavior_default_o5).I_Behavior_Default_5 
+  i_behavior_default_d.(  'i  behavior  default  ol  \  'i_behavior_default_o9).I_Behavior_Default_9 

def 

I_Behavior_Default_2  = 

i  behavior  default  a .(  'i_behavior_default_o2  \  'i_behavior _default_o3).l  Behavior _Default_3 
+  i_behavior_default_b.(  'i_behavior_default_o2  \  'i_behavior_default_oO).I_Behavior_Default_0 
+  i  behavior  default  cf  'i_behavior_default_o2  \  'i_behavior_default_o6).I_Behavior_Default_6 
+  i_behavior_default_d.(  'i_behavior_default_o2  \  'i_behavior_default_ol0).I_Behavior_Default_10 

def 

I_Behavior_Default_3  = 

i_behavior_default_a.(  'i_behavior_default_o3  \  'i_behavior  default  02). 1 Behavior  Default _2 
+  i_behavior_default_b.(  'i_behavior_default_o3  \  'i_behavior_default_ol).I_Behavior_Default_l 
+  i_behavior_default_c.(  'i_behavior_default_o3  \  'i_behavior_default_o7).I_Behavior_Default_7 
+  i_behavior_default_d.(  'i_behavior_default_o3  \  'i  behavior  default  ol l).I_Behavior_Default_l  1 

def 

I_Behavior_Default_4  = 

i_behavior  default  a .(  'i_behavior_default_o4  \  'i_behavior_default_o5).l  Behavior _Default_5 
+  i_behavior_default_b.(  'i_behavior_default_o4  |  'i_behavior_default_o6).I_Behavior_Default_6 
+  i_behavior_default_c.{  'i_behavior_default_o4  \  do).l_Behavior_Default_0 
+  i_behavior_default_d.(  'i_behavior_default_o4  \  'i  behavior  default  ol 2).I_Behavior_Default_l 2 

def 

I_Behavior_Default_5  = 

i_behavior_default_a.(  'i_behavior_default_o5  \  'i_behavior_default_o4).l  Behavior _Default_4 
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+  i_behavior_default_b.{  'i_behavior_default_o5  \  'i_behavior_default_o7).l_Behavior_Default_7 
+  i _behavior _default_c.(  'i_behavior_default_o5  \  'i_behavior_default_ol).I_Behavior_Default_l 
+  i _behavior -default _d.(  'i_behavior_default_o5  \  'i_behavior_default_ol 3).I_Behavior_Default_l 3 

def 

I_Behavior_Default_6  = 

i _behavior -default _a.(  'i_behavior_default_o6  \  'ibehavior -default _o7).l  Behavior -Default _7 
+  i -behavior -default _b.{  'i_behavior_default_o6  \  'i_behavior_default_o4).I_Behavior_Default_4 
+  i _behavior -default _c.(  'i_behavior_default_o6  \  'i_behavior_default_o2).I_Behavior_Default_2 
+  i -behavior -default _d.(  'i_behavior_default_o6  \  'i_behavior_default_ol4).I_Behavior_Default_14 

def 

I-Behavior_Default_7  = 

i  beha vior_defaull_a. (  'i  behavior  default _o7  \  'i_behavior_default_o6).l  Behavior _Default_6 
+  i -behavior _def aid t_b.{  'i_behavior_default_o7  \  'i_behavior_default_o5).I_Behavior_Default_5 
+  i -behavior _def aidt -C.{  'i_behavior_default_o7  \  'i_behavior_default_o3).I_Behavior_Default_3 
+  i -behavior -default _d.(  'i_behavior_default_o7  \  'i_behavior_default_ol 5).I_Behavior_Default_l 5 

def 

I -Behavior -Default _8  — 

i  beha vior_defaull_a. (  'i_behavior -default _o8  \  'i_behavior_default_o9).I  Behavior  Default_9 
+  i -behavior _def aid t_b.{  'i_behavior_default_o8  \  'i_behavior_default_ol0).I_Behavior_Default_10 
+  i -behavior -default _c.(  'i -behavior -default _o8  \  'i_behavior_default_ol23).I_Behavior_Default_12 
+  i -behavior -default _d.(  'i_behavior_default_o8  \  'i_behavior_default_oO).I_Behavior_Default_0 

d£ 

I_Behavior_Default_9  ~ 

i -behavior  default  a.  ( 'i_behavior_default_o9  \  'i_behavior_default_o8).I  Behavior_Default_8 
+  i _behavior _def aid t_b.(  'i_behavior_default_o9  \  'i  behavior  default  ol l).I_Behavior_Default_l  1 
+  i -behavior -default _c.(  'i_behavior_default_o9  \  'i_behavior_default_ol 3).I -Behavior -Default _1 3 
+  i_behavior_default_d.(  'i_behavior_default_o9  \  'i_behavior_default_ol).I_Behavior_Default_l 

def 

I  Behavior  Default _10  ~ 

i -behavior -default _a.(  'i_behavior_default_olO  \  'i  behavior  default  ol  1). I  Behavior  Default _1 1 
+  i -behavior -default _b.{  'i_behavior_default_olO  \  'i_behavior_default_o8).I  Behavior_Default_8 
+  i -behavior -default _c.(  'i  behavior  default  olO  \  'i_behavior_default_ol4).l_Behavior_Default_14 
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+  i_behavior_default_d.(  'i_behcivior_default_olO  \  'i_behavior_default_o2).I_Behavior_Default_2 

def 

I_Behavior_Default_l  1  ~ 

i _behavior _default _ci.(  'ibehaviordefaultol  1  \  'i_behavior_default_o  10). I  Behavior -Default _10 
+  i _behavior -default _b.(  'i  behavior  default  ol  1  \  'i_behavior_default_o9).I_Behavior_Default_9 
+  i -behavior -default _c.{  'i  behavior  default  ol  1  \  'i -behavior  default _ol 5).I_Behavior_Default_l 5 
+  i_behavior_default_d.(  'i_behavior_default_ol  1  \  'i_behavior_default_o7).I_Behavior_Default_7 

def 

I-Behavior_Default_l 2  ~ 

i -behavior  default _a.  ( 'i_behavior_default_ol2  \  'i -behavior  default _ol 3).I_Behavior_Default_l 3 
+  i -behavior _def aull_b.(  'i_behavior_default_ol2  \  'i_behavior_default_ol4).l_Behavior_Default_14 
+  i -behavior -default _c.(  'i_behavior_default_ol2  \  'i_behavior_default_o8).I_Behavior_Default_8 
+  i_behavior_default_d.(  'i  behavior  default _o  12  \  'i_behavior_default_o4).I_Behavior_Default_4 

def 

I  -Behavior -Default _13  ~ 

i  behavior  default  a.  (  'i_behavior_default_ol3  \  'i -behavior _dej ault  o  12). I  Behavior  Default  12 
+  i -behavior -default _b.(  'i  behavior  default  ol 3  \  'i  behavior  default  ol 5).I_Behavior_Default_l 5 
+  i -behavior -default _cf  'i_behavior_default_ol3  \  'i_behavior_default_ol9).I_Behavior_Default_19 
+  i -behavior  def ault  df  'i  behavior  default  ol 3  \  'i_behavior_default_o5).I_Behavior_Default_5 

def 

I  Behavior_Default_14  ~ 

i  behavior  default  a.  (  'i_behavior_default_ol4  \  'i -behavior -default _ol 5). I  Behavior  Default _1 5 
+  i -behavior -default _bf  'i_behavior_default_ol4  \  'i_behavior -default _ol2).I  Behavior -Default _12 
+  i -behavior -default _cf  'i_behavior_default_ol4  \  'i_behavior_default_ol0).I_Behavior_Default_10 
+  i_behavior_default_d.(  'i_behavior_default_ol 4  \  'i_behavior_default_o6).I_Behavior_Default_6 

def 

I -Behavior -Default _13  ~ 

i  behavior  default  a.  (  'i  behavior  default  ol 5  \  'i  behavior  default  ol 4).I_Behavior_Default_l 4 
+  i -behavior _def aull_b.(  'i  behavior  default  ol 5  \  'i_behavior_default_ol3).I_Behavior_Default_13 
+  i -behavior -default -C.(  'i -behavior -default _ol 5  \  'i  behavior  default  ol l).I_Behavior_Default_l  1 
+  i -behavior  def  aultdf  'ibehaviordefaultol  5  \  'i_behavior_default_o7).IBehavior_Default_7 
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def 

J_Behavior_Default_0  = 

jbehavior default  a.  'jbehaviordefaultoO.  'jbehaviordefaultol  JBehaviorDefaultl 
+ j _behavior _default_b.  j_behavior_default_oO.  j_behavior _default_o2.J  Behavior _Default_2 
+ j _behavior  default _c.  'j  behavior  default  oO.  'j_behavior_defaidt_o4.J_Behavior_Default_4 
+ j _behavior  default  d.'j behaviordefaultoO.  j _behavior_default_o8 J  Behavior _Default_8 

def 

J_Behavior_Default_l  = 

jbehaviordefaulta.  j_behavior_default_oO .  j_behavior_default_ol .J  Behavior _Default_0 
+ jbehaviordefaultb.  'j  behavior  default _ol .  j _behavior_default_o3  J_Behavior_Default_3 
+ j _behavior_default_c.  j  behavior  default  ol .  j _behavior_default_o5  J_Behavior_Default_5 
+ j _behavior_default_d.  'j_behavior  default _ol .  j_behavior_defaidt_o9J_Behavior_Default_9 

def 

J_Behavior_Default_2  = 

j_behavior_default_a.  j _behavior_default_o2  .  'j_behavior  default j)3.J  Behavior _Default_3 
+ j _behavior_default_b.  j  behavior  default  oO  .  'j_behavior_default_o2.J_Behavior_Default_0 
+ j _behavior_default_c.  j  behavior  default _o2  .  j_behavior_defaidt_o6.J_Behavior_Default_6 
+ j  behavior  def ault  d.  j  behavior  default _o2  .  j _behavior _default_olO.J  Behavior _Default _10 

def 

J_Behavior_Default_3  = 

j  behavior  default  a.  'j  behavior  def ault_o2  .  j  behavior _default_o3.J  Behavior _Default_2 
+ j _behavior_default_b.  'j_behavior  default _ol .  'j_behavior_default_o3.J_Behavior_Default_l 
+ j  behavior  def ault  c.  j  behavior  default _o3  .  j _behavior_default_o7 J  Behavior _Default_7 
+ j  behavior  def  aultd.  jbehavior default _o3  .  j_behavior_default_ol  1  .J J3ehavior_Default_l  1 

def 

J_Behavior_Default_4  — 

j_behavior  default  a.  j  behavior  default _o4 .  j_behavior_default_o5.J_Behavior_Defaidt_5 
+ j _behavior_default_b.  j  behavior  default _o4  .  'j_behavior_default_o6J_Behavior_Default_6 
+ j  behavior  def ault_c.  'j_behavior_default_oO  .'j_behavior_default_4.J  Behavior _Default_0 
+ j  behavior  default  d.  j  behavior  default _o4  .  'j_behavior_default_ol2J_Behavior_Default_12 

def 

J_Behavior_Default_5  = 

j  behavior  default  a.  'j jbehavior  default _o4 .  j_behavior_default_o5.J_Behavior_Default_4 


E-6 


+ j behavior  def ault  b.  ] _behavior_default_o5  .  j _behavior_default_o7 .J  Behavior _Default_7 
+ j  behavior  def ault_c.  'jbehavior default _ol .  j _behavior_default_o5  JBehaviorDefaultl 
+ j  -behavior  defaultd.  'j  behavior  default _o 5  .  'j_behavior_default_ol3.J_Behavior_Default_13 

def 

JBehavior_Default_6  = 

j _behavior  default  a.  j_behavior_default_o6 .  j -behavior -default _o 7. J  Behavior _Default_7 
+ j  behavior  def  aultb.  ] -behavior  default _o4  .  j -behavior _default_o6.J  Behavior _Default_4 
+ j _behavior_default_c.  j -behavior  default _o2  .  'j  behavior _default_o6J  Behavior _Default_2 
+ j -behavior  default  d.  j -behavior  default  06 .  j_behavior_default_ol4.J_Behavior_Default_14 

def 

J  Behavior -Default _7  = 

j -behavior  default  a.  'j -behavior -default _o6 .  ]  behavior  def aulto  7.  J -Behavior -Default _6 
+ j  behavior  default  b.  ] -behavior  default _o 5  .  ] -behavior _default_o7. J  Behavior _Default_5 
+ j _behavior_default_c.  j -behavior default _o3  .  j -behavior -default _o7 J  Behavior -Default _3 
+ j  -behavior  defaultd.  ] -behavior  default _o7 .  j -behavior defaultol  5. JBehaviorDefaultl  5 

def 

J  Behavior -Default _8  = 

j -behavior  default  a.  j_behavior_default_o8  .  ] -behavior _default_o9.J -Behavior -Default _9 
+ j  behavior  default  b.  j_behavior_default_o8  .  ]_behavior_default_ol0.J  Behavior_Default_10 
+ j  -behavior _default_c.  'j_behavior_default_o8  .  j -behavior _dej aultol  2  J Behavior Default  12 
+ j -behavior  default  d.  ] -behavior  default  oO  .  ]_behavior_default_o8.J_Behavior_Default_0 

d£ 

J  Behavior_Default_9  ~ 

j -behavior  default  a.  j_behavior_default_oO .  ] -behavior -default _o9.J  Behavior _Default_8 
+ jbehaviordefaultb.  'j -behavior  default _o9  .  j  -behavior  defaultol  1  .JBehaviorDefaultl  1 
+ j  -behavior _default_c.  j -behavior -default _o9  .  'j_behavior_default_ol3.JBehavior_Default_13 
+ j _behavior_default_d.  'j -behavior  default _ol .  j_behavior_default_o9.J_Behavior_Default_l 

d^_ 

J  Behavior _Default_10  ~ 

j -behavior  default  a.  j _behavior_default_olO  .  'jbehaviordefaultol  1  .JBehaviorDefaultl  1 
+ j  -behavior _default_b.  j  -behavior _default_o8  .  'j_behavior_default_olO.JBehavior_Default_8 
+ j _behavior_default_c.  'j_behavior_default_ol 0 .  j_behavior_default_ol4.J_Behavior_Default_14 
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+ jbehaviordefaultd.  'j  behavior  default _o2  .  'j_behavior_default_olO.J_Behavior_Default_2 

d£ 

J  Behavior _Defciult _1 1  ~ 

j fbehavior  default  a.  j_behavior_default_olO  .  'j -behavior  default  ol  1  .J  Behavior  Default  l  0 
+ j  behavior  default  b.  ] -behavior  default _o9  .  j_behavior_default_oll.JBehavior_Default_9 
+ j  -behavior  defaultc.  ] -behavior _default_ol  1 .  'j -behavior  defaultol  5J_Behavior_Default_l  5 
+ j  behavior  default  d.  ] -behavior  default _o7 .  j -behavior  default  ol  1  .J_Behavior_Default_7 

d£ 

J  Behavior_Default_12  ~ 

j -behavior  default  a.  j -behavior _default_o  12  .  j -behavior defaultol  3. J Behavior Default  13 
+ j  -behavior _default_b.  j -behavior default _o  12  .  j_behavior_default_ol4.J_Behavior_Default_14 
+ j _behavior_default_c.  'j_behavior_default_o8  .  ]_behavior_default_ol2.J  Behavior_Default_8 
+ j  behavior  default  d.  'j -behavior  default _o4  .  'j -behavior _default_ol2.J  Behavior _Default_4 
J  Behavior _Default_l 3  ~ 

j -behavior  default  a.  j  -behavior _default_o  12  .  'j -behavior defaultol  3. J Behavior Default  12 
+ j  -behavior _default_b.  'j -behavior  default _o  13  .  j -behavior _default_ol  5.J -Behavior -Default _1 5 
+  j _behavior_default_c.  j_behavior_default_o9  .  j -behavior -default _ol 3.. J  Behavior  Default  19 
+ j  behavior  default  d.  'j -behavior  default _o5  .  'j_behavior_default_ol3.J_Behavior_Default_5 
J  Behavior_Default-14  ~ 

j -behavior  default  a.  j  -behavior _default_o  14  .  'j -behavior  defaultol  5. J  Behavior  Default  15 
+ j  -behavior _default_b.  'j -behavior  default _o  12  .  'j -behavior  defaultol  4.J_Behavior_Default_l  2 
+ j _behavior_default-C.  j_behavior_default_olO .  j_behavior_default_ol4.J_Behavior_Default_10 
+ j  -behavior  defaultd.  'j -behavior  default _o6 .  'j_behavior_default_ol4.J_Behavior_Default_6 

d4_ 

J  -Behavior _Default_l  5  ~ 

j -behavior  default  a.  j  -behavior _default_o  14  .  j -behavior _default_o  1 5.  J  Behavior -Default _1 4 
+ j  behavior  default  b.  'j -behavior  default _o  13  .  j _behavior_default_ol 5.J -Behavior -Default _1 3 
+ j  -behavior  defaultc.  'j -behavior -default  oil .  'j -behavior  defaultol  5.J_Behavior_Default_l  1 
+ j  behavior  default  d.  'j -behavior  default _o7 .  j_behavior_default_ol5.J  Behavior_Default_7 
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